From: Andreas Gruenbacher <agruen@suse.de>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: James Morris <jmorris@namei.org>,
Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>
Subject: Re: [patch 2/2] Access Control Lists for tmpfs
Date: Tue, 10 Jan 2006 15:01:32 +0100 [thread overview]
Message-ID: <200601101501.33298.agruen@suse.de> (raw)
In-Reply-To: <1136897452.19934.125.camel@moss-spartans.epoch.ncsc.mil>
On Tuesday 10 January 2006 13:50, Stephen Smalley wrote:
> On Mon, 2006-01-09 at 00:01 +0100, Andreas Gruenbacher wrote:
> > plain text document attachment (tmpfs-acl.diff)
> > Add access control lists for tmpfs.
> >
> > Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
> >
> > Index: linux-2.6.15-git4/mm/shmem.c
> > ===================================================================
> > --- linux-2.6.15-git4.orig/mm/shmem.c
> > +++ linux-2.6.15-git4/mm/shmem.c
> > @@ -1843,6 +1852,50 @@ static struct inode_operations shmem_sym
> > .put_link = shmem_put_link,
> > };
> >
> > +#ifdef CONFIG_TMPFS_POSIX_ACL
> > +/* The vfs implements defaults for the security.* xattr namespace for
> > inodes + * that don't have xattr iops. We have xattr iops for the acls,
> > so we must + * also implement the security.* defaults here.
> > + */
> > +static size_t shmem_xattr_security_list(struct inode *inode, char *list,
> > + size_t list_len, const char *name,
> > + size_t name_len)
> > +{
> > + return security_inode_listsecurity(inode, list, list_len);
> > +}
> > +
> > +static int shmem_xattr_security_get(struct inode *inode, const char
> > *name, + void *buffer, size_t size)
> > +{
> > + if (strcmp(name, "") == 0)
> > + return -EINVAL;
> > + return security_inode_getsecurity(inode, name, buffer, size,
> > + -EOPNOTSUPP);
> > +}
> > +
> > +static int shmem_xattr_security_set(struct inode *inode, const char
> > *name, + const void *value, size_t size, int flags)
> > +{
> > + if (strcmp(name, "") == 0)
> > + return -EINVAL;
> > + return security_inode_setsecurity(inode, name, value, size, flags);
> > +}
> > +
> > +struct xattr_handler shmem_xattr_security_handler = {
> > + .prefix = XATTR_SECURITY_PREFIX,
> > + .list = shmem_xattr_security_list,
> > + .get = shmem_xattr_security_get,
> > + .set = shmem_xattr_security_set,
> > +};
>
> This seems like a regression, given that this code was just removed in
> 2.6.14 by the generic VFS fallback support for security xattrs,
> http://marc.theaimsgroup.com/?l=git-commits-head&m=112597810414161&w=2
>
> Could you instead provide a generic VFS fallback for ACLs as well?
Correct, this was when tmpfs only supported security.* xattrs. I didn't like
this cleanup very much: it removed some reasonably clean abstractions and
piled up more crap in fs/xattr.c instead. The security.* xattr code in
fs/xattr.c is not extensible, which is why this patch needs to bring back
some of the code that was removed. It would be possible to change that code
so that it works no matter if an inode has xattr iops, but this would require
a super_block flag that indicates if an inode's xattr ops implement the
security.* namespace.
Generic acl support would amount to adding i_acl and i_default_acl pointers to
generic inodes. I'm not sure if this is acceptable: Ext2, ext3, reiserfs, jfs
have those pointers in their in-memory inodes but others don't, and generic
acls only makes sense for memory-based filesystems. The wiring code needed in
filesystems doesn't seem so horrible to me.
ACLs are slightly different from security labels, too: labeled security
protection needs a label on everything, ACLs are not needed everywhere.
Thanks,
Andreas.
prev parent reply other threads:[~2006-01-10 14:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060108230116.073177000@blunzn.suse.de>
2006-01-08 23:01 ` [patch 1/2] Generic infrastructure for acls Andreas Gruenbacher
2006-01-09 15:40 ` James Morris
2006-01-08 23:01 ` [patch 2/2] Access Control Lists for tmpfs Andreas Gruenbacher
2006-01-09 15:40 ` James Morris
2006-01-09 18:33 ` Andi Kleen
2006-01-10 12:50 ` Stephen Smalley
2006-01-10 14:01 ` Andreas Gruenbacher [this message]
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=200601101501.33298.agruen@suse.de \
--to=agruen@suse.de \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome