Message-ID: <533428BF.8090007@gmail.com>
Date:	Thu, 27 Mar 2014 15:33:51 +0200
From:	Boaz Harrosh <openosd@...il.com>
To:	Florian Weimer <fweimer@...hat.com>,
	Jeff Layton <jlayton@...hat.com>, Jim Lieb <jlieb@...asas.com>
CC:	Andy Lutomirski <luto@...capital.net>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	LSM List <linux-security-module@...r.kernel.org>,
	"Serge E. Hallyn" <serge@...onical.com>,
	Kees Cook <keescook@...omium.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Theodore Ts'o <tytso@....edu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	bfields@...hat.com
Subject: Re: Thoughts on credential switching

On 03/27/2014 03:06 PM, Florian Weimer wrote:
> On 03/27/2014 02:02 PM, Jeff Layton wrote:
> 
>>> This interface does not address the long-term lack of POSIX
>>> compliance in setuid and friends, which are required to be
>>> process-global and not thread-specific (as they are on the kernel
>>> side).
>>>
>>> glibc works around this by reserving a signal and running set*id on
>>> every thread in a special signal handler.  This is just crass, and it
>>> is likely impossible to restore the original process state in case of
>>> partial failure.  We really need kernel support to perform the
>>> process-wide switch in an all-or-nothing manner.
>>>
>>
>> I disagree. We're treading new ground here with this syscall. It's
>> not defined by POSIX so we're under no obligation to follow its silly
>> directives in this regard. Per-process cred switching doesn't really
>> make much sense in this day and age, IMO. Wasn't part of the spec was
>> written before threading existed
> 
> Okay, then we need to add a separate set of system calls.
> 

separate set of system calls is exactly what we do not need. The syscalls
are all per thread.

What we do need is a new set of glibc APIs to follow what everyone
who cares does now. Because no body uses the current code - setuid
and friends - The huge majority of utilities are just single threaded
and could careless. The few threaded apps that do use setuid and friends
use the SYSCALL directly.

Both samba and Ganesha have their own define of setthread_uid/setthread_gid/
setthread_groops. and avoid glibc as a plague.

man setuid should be saying DEPRECATED, EMULATED and SIGNAL NOT SAFE
and be done with it POSIX or no POSIX who cares?

and a new well define set is to be defined by glibc implemented easily
not only on Linux (MACOX FreeBSD are the same as linux)

And that is that

> I really, really want to get rid of that signal handler mess in glibc, 
> with its partial failures.
> 

I would not spend one second on an API no one uses. As I said most
users are single threaded and could care less. Few threaded users
already do direct syscalls

>> The per-process credential switching is pretty universally a pain in
>> the ass for anyone who wants to write something like a threaded file
>> server. Jeremy Allison had to jump through some rather major hoops to
>> work around it for Samba [1]. I think we want to strive to make this a
>> per-task credential switch and ignore that part of the POSIX spec.
> 
> Yeah, I get that, setfsuid/setfsgid already behaves this way.
> 
> (Current directory and umask are equally problematic, but it's possible 
> to avoid most issues.)
> 
>> That said, I think we will need to understand and document what we
>> expect to occur if someone does this new switch_creds(fd) call and then
>> subsequently calls something like setuid(), if only to ensure that we
>> don't get blindsided by it.
> 
> Currently, from the kernel perspective, this is not really a problem 
> because the credentials are always per-task.  It's just that a 
> conforming user space needs the process-wide credentials.
> 

Please show me one user of that and declare it brain dead.
POSIX or not it just does not have any real programming mining
at all. Plain and simple. Even if you made  process-wide credentials
atomic it would still mean nothing.

That said. I second Jeff's point of Jim's implementation doing
all we really need. It is fast and simple and can give us all
we need and with a single added SYSCALL. The patch is already
out there. I thought it was even considered for inclusion through
Al viro.

Cheers
Boaz

--
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