All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Brian Foster <bfoster-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Andreas Gruenbacher
	<agruen-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org>,
	xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org,
	linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2 1/2] xfs: fix tmpfile/selinux deadlock and initialize security/acl
Date: Tue, 15 Apr 2014 10:52:28 -0700	[thread overview]
Message-ID: <20140415175228.GE26404@infradead.org> (raw)
In-Reply-To: <20140410122944.GA6579-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

So any opinions from other fs / security people on how O_TMPFILE files
should behave for ACL inheritance / labeling?

On Thu, Apr 10, 2014 at 05:29:44AM -0700, Christoph Hellwig wrote:
> On Thu, Apr 10, 2014 at 08:19:48AM -0400, Brian Foster wrote:
> > Are you saying it doesn't have to initialize security or the default
> > acl, or both?
> 
> The ACLs for sure.  LSM do run-time access decisions, so they will
> probably rely on the security data being initialized.  Given that
> O_TMPFILE files aren't publicly available I'm not sure there's a point
> in them doing that, though.
> 
> LSMs are also affected by the lack of a proper parent I'll discuss for
> ACLs below.
> 
> > The intent here was to have the case covered where the inode happens to
> > be linked back into the namespace since we don't do this work in the
> > link path.
> 
> That's an interesting one.  O_TMFILE files don't have a real parent
> to inherit ACLs from, the pathname passed in just needs to point to
> a directory to find the filesystem to create the tmpfile in.  On
> the other hand it seem like the extN implementations do inherity the
> ACL in this case.
> 
> The link into the namespace is irrelavant here as ACL inheritance only
> happens on initial create, not at link time.
> 
> I also think we'll absolutely need a test case for ACLs+tmpfile to
> make sure all filesystems handle it the same way.
> 
> > The bulk of the refactoring was with the idea that the inode setup for
> > the tmpfile case is generally equivalent for the traditional create
> > case. The original version was posted here:
> > 
> > http://oss.sgi.com/archives/xfs/2014-04/msg00149.html
> > 
> > ... and it just fixes the deadlock and adds the security initialization.
> > I suppose I could still break that out into multiple patches, but that
> > aside, is that behavior preferred?
> 
> I think just fixing the deadlock and initializing the security is enough
> for the first pass.  If you want to do the refactoring on top send it as
> a second series on top of the actual fixes.
> 
> _______________________________________________
> xfs mailing list
> xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org
> http://oss.sgi.com/mailman/listinfo/xfs
---end quoted text---
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-man@vger.kernel.org,
	Andreas Gruenbacher <agruen@linbit.com>,
	xfs@oss.sgi.com, linux-security-module@vger.kernel.org,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH v2 1/2] xfs: fix tmpfile/selinux deadlock and initialize security/acl
Date: Tue, 15 Apr 2014 10:52:28 -0700	[thread overview]
Message-ID: <20140415175228.GE26404@infradead.org> (raw)
In-Reply-To: <20140410122944.GA6579@infradead.org>

So any opinions from other fs / security people on how O_TMPFILE files
should behave for ACL inheritance / labeling?

On Thu, Apr 10, 2014 at 05:29:44AM -0700, Christoph Hellwig wrote:
> On Thu, Apr 10, 2014 at 08:19:48AM -0400, Brian Foster wrote:
> > Are you saying it doesn't have to initialize security or the default
> > acl, or both?
> 
> The ACLs for sure.  LSM do run-time access decisions, so they will
> probably rely on the security data being initialized.  Given that
> O_TMPFILE files aren't publicly available I'm not sure there's a point
> in them doing that, though.
> 
> LSMs are also affected by the lack of a proper parent I'll discuss for
> ACLs below.
> 
> > The intent here was to have the case covered where the inode happens to
> > be linked back into the namespace since we don't do this work in the
> > link path.
> 
> That's an interesting one.  O_TMFILE files don't have a real parent
> to inherit ACLs from, the pathname passed in just needs to point to
> a directory to find the filesystem to create the tmpfile in.  On
> the other hand it seem like the extN implementations do inherity the
> ACL in this case.
> 
> The link into the namespace is irrelavant here as ACL inheritance only
> happens on initial create, not at link time.
> 
> I also think we'll absolutely need a test case for ACLs+tmpfile to
> make sure all filesystems handle it the same way.
> 
> > The bulk of the refactoring was with the idea that the inode setup for
> > the tmpfile case is generally equivalent for the traditional create
> > case. The original version was posted here:
> > 
> > http://oss.sgi.com/archives/xfs/2014-04/msg00149.html
> > 
> > ... and it just fixes the deadlock and adds the security initialization.
> > I suppose I could still break that out into multiple patches, but that
> > aside, is that behavior preferred?
> 
> I think just fixing the deadlock and initializing the security is enough
> for the first pass.  If you want to do the refactoring on top send it as
> a second series on top of the actual fixes.
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
---end quoted text---

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2014-04-15 17:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-09 19:21 [PATCH v2 0/2] xfs: tmpfile fixes for inode security/acl Brian Foster
2014-04-09 19:21 ` [PATCH v2 1/2] xfs: fix tmpfile/selinux deadlock and initialize security/acl Brian Foster
2014-04-10 10:24   ` Christoph Hellwig
2014-04-10 12:19     ` Brian Foster
2014-04-10 12:29       ` Christoph Hellwig
     [not found]         ` <20140410122944.GA6579-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2014-04-15 17:52           ` Christoph Hellwig [this message]
2014-04-15 17:52             ` Christoph Hellwig
2014-04-15 19:31             ` Andreas Gruenbacher
     [not found]               ` <1188577823.463241.1397590262478.JavaMail.zimbra-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org>
2014-04-16 11:14                 ` Christoph Hellwig
2014-04-16 11:14                   ` Christoph Hellwig
2014-04-16 17:29                   ` Andreas Gruenbacher
     [not found]                     ` <359356562.473582.1397669369258.JavaMail.zimbra-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org>
2014-04-18 16:39                       ` Christoph Hellwig
2014-04-18 16:39                         ` Christoph Hellwig
2014-04-30 12:02   ` Christoph Hellwig
2014-04-09 19:21 ` [PATCH v2 2/2] xfs: fold xfs_create_tmpfile() into xfs_create() Brian Foster
2014-04-10 10:29   ` Christoph Hellwig
2014-04-10 12:19     ` Brian Foster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140415175228.GE26404@infradead.org \
    --to=hch-wegcikhe2lqwvfeawa7xhq@public.gmane.org \
    --cc=agruen-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org \
    --cc=bfoster-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    --cc=xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.