[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87hacgk0yt.fsf@xmission.com>
Date: Wed, 16 Oct 2013 20:52:58 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Jim Lieb <jlieb@...asas.com>, tytso@....edu, viro@...iv.linux.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
bfields@...hat.com, jlayton@...hat.com
Subject: Re: [PATCH 1/3] switch_creds: Syscall to switch creds for file server ops
Al Viro <viro@...IV.linux.org.uk> writes:
> On Wed, Oct 16, 2013 at 06:18:16PM -0700, Eric W. Biederman wrote:
>
>> That doesn't look bad but it does need capable(CAP_SETUID) &&
>> capable(CAP_SETGID) or possibly something a little more refined.
>
> D'oh
>
>> I don't think we want file descriptor passing to all of a sudden become
>> a grant of privilege, beyond what the passed fd can do.
>
> Definitely. And an extra ) to make it compile wouldn't hurt either...
There also appears to need to be a check that we don't gain any
capabilities.
We also need a check so that you don't gain any capabilities, and
possibly a few other things.
So I suspect we want a check something like:
if ((new_cred->securebits != current_cred->securebits) ||
(new_cred->cap_inheritable != current_cred->cap_inheritable) ||
(new_cred->cap_permitted != current_cred->cap_permitted) ||
(new_cred->cap_effective != current_cred->cap_effective) ||
(new_cred->cap_bset != current_cred->cap_bset) ||
(new_cred->jit_keyring != current_cred->jit_keyring) ||
(new_cred->session_keyring != current_cred->session_keyring) ||
(new_cred->process_keyring != current_cred->process_keyring) ||
(new_cred->thread_keyring != current_cred->thread_keyring) ||
(new_cred->request_keyring != current_cred->request_keyring) ||
(new_cred->security != current_cred->security) ||
(new_cred->user_ns != current_cred->user_ns)) {
return -EPERM;
}
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists