Re: metadata race confition (was: ename(2) race condition)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, May 21, 2012 at 10:33 PM, Emmanuel Dreyfus <manu@xxxxxxxxxx> wrote:
Anand Avati <anand.avati@xxxxxxxxx> 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

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux