[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140418163920.GB13808@infradead.org>
Date: Fri, 18 Apr 2014 09:39:20 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Andreas Gruenbacher <andreas.gruenbacher@...bit.com>
Cc: Christoph Hellwig <hch@...radead.org>,
Brian Foster <bfoster@...hat.com>, linux-man@...r.kernel.org,
xfs@....sgi.com, linux-security-module@...r.kernel.org,
Al Viro <viro@...iv.linux.org.uk>,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH v2 1/2] xfs: fix tmpfile/selinux deadlock and initialize
security/acl
On Wed, Apr 16, 2014 at 07:29:29PM +0200, Andreas Gruenbacher wrote:
> > Btw, I think the man page is wrong - given that the tmpfile is not
> > visible in the namespace it is obviously not created in the directory.
> > The directory passed in is just a handle for the filesystem it should be
> > created in.
>
> I don't agree. If the file is created with O_TMPFILE | O_EXCL, it is clear
> that the file will never be linked into the namespace. Even then, there are
> operations which are affected by the inode permissions and label of the
> anonymous file, and those should still behave reasonably. In this context,
> I would expect them to behave as if the file was actually created in the
> specified directory, not in the file system root or "nowhere" with no clearly
> defined permissions and security label.
So you want to define the files as being in a directory, but not
actually visible? That's defintively a new and strange state to be in.
> > Inheriting any ACL on creating an anonymous file seems utterly wrong.
>
> Why?
Because it has no parent to inherit it from.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists