On Mon, Jan 05, 2009 at 05:19:37PM +0000, David Howells wrote:
> Fix a regression in NFSD's permission checking introduced by the credentials
> patches. There are two parts to the problem, both in nfsd_setuser():
>
> (1) The return value of set_groups() is -ve if in error, not 0, and should be
> checked appropriately. 0 indicates success.
>
> (2) The UID to use for fs accesses is in new->fsuid, not new->uid (which is
> 0). This causes CAP_DAC_OVERRIDE to always be set, rather than being
> cleared if the UID is anything other than 0 after squashing.
>
> Reported-by: J. Bruce Fields <bfields@xxxxxxxxxxxx>
> Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
OK, I've tested this and applied it for 2.6.29.
Though it only actually fixes the regression if your other patch ("CRED:
Fix regression in cap_capable() as shown up by sys_faccessat() [ver #2")
is also applied. I'd like to send in my pull request today, but I
usually try not to send a pull request whose tip doesn't pass at least
my basic regression tests.... And that other patch is outside my
baliwick. Can someone else handle it?
--b.
> ---
>
> fs/nfsd/auth.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/fs/nfsd/auth.c b/fs/nfsd/auth.c
> index 0184fe9..c903e04 100644
> --- a/fs/nfsd/auth.c
> +++ b/fs/nfsd/auth.c
> @@ -76,10 +76,10 @@ int nfsd_setuser(struct svc_rqst *rqstp, struct svc_export *exp)
>
> ret = set_groups(new, gi);
> put_group_info(gi);
> - if (!ret)
> + if (ret < 0)
> goto error;
>
> - if (new->uid)
> + if (new->fsuid)
> new->cap_effective = cap_drop_nfsd_set(new->cap_effective);
> else
> new->cap_effective = cap_raise_nfsd_set(new->cap_effective,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
