All of lore.kernel.org
 help / color / mirror / Atom feed
From: Timothy Shimmin <tes@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 3/3] use inode_change_ok for setattr permission checking
Date: Wed, 12 Nov 2008 15:24:13 +1100	[thread overview]
Message-ID: <491A5A6D.5040802@sgi.com> (raw)
In-Reply-To: <20081111222414.GA9134@infradead.org>

Christoph Hellwig wrote:
> On Wed, Oct 29, 2008 at 05:35:11PM +1100, Timothy Shimmin wrote:
>> Christoph Hellwig wrote:
>>> Instead of implementing our own checks use inode_change_ok to check for
>>> nessecary permission in setattr.  
>> Yeah, the 1st bit I quite like and is similar to what I did in some
>> nfs4acl code, as you know.
>> We put all the EPERM cases early on which is nice.
> 
> Yes.  The big differene to the NFSv4 ACL patches is that we use the
> standard kernel inode_change_ok routine, which means we are guaranteed
> to have the same checks as all other filesystems and get rid of
> duplicated code.
> 
> Btw, I must also say that I really hate the way the NFSv4 ACL patches make
> this filesystem-specific for all filesystems that support the NFSv4
> ACLs.  All these permission checks should instead go through
> ->permission with additional MAY_ flags.
> 
Yeah, it would be nice to have more out of the filesystem.

>> And then we have similar code in inode_setattr()
>>         if (ia_valid & ATTR_MODE) {
>>                 umode_t mode = attr->ia_mode;
>>
>>                 if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID))
>>                         mode &= ~S_ISGID;
>>                 inode->i_mode = mode;
>>         }
>>
>> But what about the suid case?
> 
> SUID is handled in the inode_change_ok bit you quoted earlier.  

For some reason I can't see where? Sorry.
I see the sgid clear but not the suid clear. D'oh.


> But we
> should add this S_ISGID handling here to XFS, too.
> 
>> And also, what is with the ATTR_KILL_* bits?
>> Lemme look...
> 
> ATTR_KILL_SUID/ATTR_KILL_SGID is a rather special thing added for NFS
> which doesn't want to do these locally but only on the server.  Local
> filesystems can simply ignore it.
> 
Thanks for the explanation.

> Updated patch below.  Note that the S_ISGID hadling required moving
> the ATTR_MODE handling after the ATTR_GID handling.
> 

So from above we have:

notify_change(struct dentry * dentry, struct iattr * attr):

>         if (inode->i_op && inode->i_op->setattr) {
>                 error = security_inode_setattr(dentry, attr);
>                 if (!error)
>                         error = inode->i_op->setattr(dentry, attr);


>         } else {
>                 error = inode_change_ok(inode, attr);
>                 if (!error)
>                         error = security_inode_setattr(dentry, attr);
>                 if (!error) {
>                         if ((ia_valid & ATTR_UID && attr->ia_uid != inode->i_uid) ||
>                             (ia_valid & ATTR_GID && attr->ia_gid != inode->i_gid))
>                                 error = DQUOT_TRANSFER(inode, attr) ? -EDQUOT : 0;
>                         if (!error)
>                                 error = inode_setattr(inode, attr);
>                 }
>         }

So in our case i_op->setattr -> xfs_setattr
And xfs_setattr will now call inode_change_ok().
So we should have similar code to inode_setattr.

So why do we do sgid clear in inode_setattr() as well as in inode_change_ok()?
Doesn't inode_change_ok propagate the attr->ia_mode change back?

Okay, the SGID clearing for mode setting seems fine.

However, we really should have a QA test for this stuff.
Something is bound to stuff up here.

--Tim

  reply	other threads:[~2008-11-12  4:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-29 21:53 [PATCH 3/3] use inode_change_ok for setattr permission checking Christoph Hellwig
2008-10-07 20:30 ` Christoph Hellwig
2008-10-29  6:35 ` Timothy Shimmin
2008-11-11 22:24   ` Christoph Hellwig
2008-11-12  4:24     ` Timothy Shimmin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-10-26 20:35 Christoph Hellwig
2008-10-27 13:36 Christoph Hellwig
2008-10-28  3:00 ` Dave Chinner

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=491A5A6D.5040802@sgi.com \
    --to=tes@sgi.com \
    --cc=hch@infradead.org \
    --cc=xfs@oss.sgi.com \
    /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.