On Mon, May 21, 2012 at 10:33 PM, Emmanuel Dreyfus <[email protected]> wrote:
> Anand Avati <[email protected]> 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
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
