[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53565491.702@redhat.com>
Date: Tue, 22 Apr 2014 13:37:53 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Boaz Harrosh <openosd@...il.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 02:33 PM, Boaz Harrosh wrote:
> man setuid should be saying DEPRECATED, EMULATED and SIGNAL NOT SAFE
> and be done with it POSIX or no POSIX who cares?
The glibc side cares, and there's also this bit: "It aims towards POSIX
and Single UNIX Specification compliance.", which should be familiar.
I get that POSIX doesn't do what people want here (umask and current
directory handling are another story). But it hasn't really helped that
some folks just said "POSIX sucks" and did their own thing, completely
bypassing the system interfaces, instead of getting things fixed
properly. Now we have to balance the kernel behavior, POSIX demands,
glibc dirty hacks to implement the questionable POSIX behavior on top of
the kernel interfaces, and more dirty hacks to work around glibc because
some applications do not like it.
I would really like to clean up this mess, but it's not clear to me
where to start.
> Please show me one user of that and declare it brain dead.
Safely and demonstratively relinquishing elevated privileges.
> POSIX or not it just does not have any real programming mining
> at all.
What do you mean with "mining" in this context?
--
Florian Weimer / Red Hat Product Security Team
--
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