[Gluster-devel] metadata race confition (was: ename(2) race condition)

[Anand Avati]

On Mon, May 21, 2012 at 10:33 PM, Emmanuel Dreyfus <manu at netbsd.org> wrote:

> Anand Avati <anand.avati at gmail.com> wrote:
>
> > Is the FUSE SETATTR implementation in NetBSD synchronous? i.e, does the
> > chown() or chmod() syscall issued by the application strictly block till
> > GlusterFS's fuse_setattr_cbk() is called?
>
> I have been able to narrow the test down to the code below, which does not
> even
> call chown().
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <err.h>
> #include <sysexits.h>
>
> int
> main(void)
> {
>        int fd;
>
>        (void)mkdir("subdir", 0755);
>
>        do {
>                if ((fd = open("subdir/bugc1.txt", O_CREAT|O_RDWR, 0644))
> == -1)
>                        err(EX_OSERR, "open failed");
>
>                if (close(fd) == -1)
>                        err(EX_OSERR, "close failed");
>
>                if (unlink("subdir/bugc1.txt") == -1)
>                        err(EX_OSERR, "unlink failed");
>        } while (1 /*CONSTCOND */);
>
>        /* NOTREACHED */
>        return EX_OK;
> }
>
> It produces a FUSE trace without SETATTR:
>
> > unique = 393, nodeid = 3098542496, opcode = LOOKUP (1)
> < unique = 393, nodeid = 3098542496, opcode = LOOKUP (1), error = -2
> > unique = 394, nodeid = 3098542496, opcode = CREATE (35)
> < unique = 394, nodeid = 3098542496, opcode = CREATE (35), error = 0
>
>  -> I suspect (not yet checked) this is the place where I get
> fuse_entry_out
> with attr.uid = 0. This will be cached since attr_valid tells us to do so.
>
> > unique = 395, nodeid = 3098542396, opcode = RELEASE (18)
> < unique = 395, nodeid = 3098542396, opcode = RELEASE (18), error = 0
> > unique = 396, nodeid = 3098542296, opcode = LOOKUP (1)
> < unique = 396, nodeid = 3098542296, opcode = LOOKUP (1), error = 0
>
> From other traces, I can tell that this last lookup is for the parent
> directory
> (subdir). The FUSE request for looking up bugc1.txt with the intent of
> deleting
> is not even sent: from cached uid we obtained from fuse_entry_out, we know
> that
> permissions shall be denied (I had a debug printf to check that). We do
> not even
> ask.
>
>
Even in the case where bugc1.txt got a wrong uid returned (assuming so), it
should not influence the permissibility of it getting deleted. The
deletability of a file is based on the permissions on the parent directory
and not the ownership of the file (unless +t sticky bit was set on the
directory).

Is there a way you can extend the trace code above to show the UIDs getting
returned? Maybe it was the parent directory (subdir) that got a wrong UID
returned?

Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120521/330cefbf/attachment-0003.html>