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
On 04/22/2014 02:37 PM, Florian Weimer wrote:
> On 03/27/2014 02:33 PM, Boaz Harrosh wrote:
>> POSIX or not it just does not have any real programming mining
>> at all.
>
> What do you mean with "mining" in this context?
>
Sorry I saw this mistake after I posted. I meant "meaning".
What I'm saying is that the mess starts when you are trying
to keep patching a very wrong API. the POSIX politics aside,
in regard to user switching (and current directory and etc...)
this API is plain WRONG. I mean in the mathematical sense wrong.
All these application mess is not the application programmers
fault. He had to do what he had to do. The mess starts when you
are trying to keep a mathematical contradiction in your proof.
It is glibc mess for trying to maintain compatibility with
these "PROCESS WIDE OPERATIONS". And naming it holy names like
POSIX will not cover the mess that they are. As long as you try
to keep them there will be mess. If you want to honestly clean
things up is by throwing the true garbage out. Convert all legacy
code to new mathematically sound API's.
Peace
Boaz
On Tuesday, April 22, 2014 15:14:33 Boaz Harrosh wrote:
> On 04/22/2014 02:37 PM, Florian Weimer wrote:
> > On 03/27/2014 02:33 PM, Boaz Harrosh wrote:
> >> POSIX or not it just does not have any real programming mining
> >> at all.
> >
> > What do you mean with "mining" in this context?
>
> Sorry I saw this mistake after I posted. I meant "meaning".
>
> What I'm saying is that the mess starts when you are trying
> to keep patching a very wrong API. the POSIX politics aside,
> in regard to user switching (and current directory and etc...)
> this API is plain WRONG. I mean in the mathematical sense wrong.
>
> All these application mess is not the application programmers
> fault. He had to do what he had to do. The mess starts when you
> are trying to keep a mathematical contradiction in your proof.
>
> It is glibc mess for trying to maintain compatibility with
> these "PROCESS WIDE OPERATIONS". And naming it holy names like
> POSIX will not cover the mess that they are. As long as you try
> to keep them there will be mess. If you want to honestly clean
> things up is by throwing the true garbage out. Convert all legacy
> code to new mathematically sound API's.
>
> Peace
> Boaz
I don't want to keep this churning thread going. I'd rather solve today's
problems. So let's put this in perspective and move on. Our project has a
problem to solve.
I wouldn't necessarily say wrong, simply very out of date. All of these
issues with POSIX and pthreads in particular come from one common source, the
actual capabilities of the systems, BSD, and SysV at the time. The goofy
localtime_r and friends were (and still are) hacks to work around the
simplistic interfaces in the original Bell Labs code that deeply assumed a
single process with a single thread, i.e. there were only 3 segments, no
shared libraries or shared r/w memory and definitely no (real) TLS. The
pthreads interfaces deeply assumed the same. Even worse, it had to also run
on VMS which (I don't believe) ever had kernel support for multiple user space
theads. ASTs are nasty enough and only worked because everybody knew that you
were either in app code or the AST... So all of this stuff is based on lowest
common denominator. The "Single UNIX Specification" was a peace treaty among
warring computer companies out looking for lock-ins and competitive advantages
while reluctantly realizing that the ISV community (Oracle) really didn't care
about anything but a common base.
Let's move on. Glibc has to keep some semblance of POSIX in order to cope
with legacy code from that era and I commend them for their perseverance. But
that should not hold us back from leveraging today's architectures and, more
importantly, today's multi-client workloads. If that means extensions to
POSIX fine. But if POSIX gets hung up because *BSD doesn't have kernel support
for thread level creds and *bsd.org doesn't want to do it, we just do what fits
today's requirements and what Linux is capable of,
Jim
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
"If ease of use was the only requirement, we would all be riding tricycles"
- Douglas Engelbart 1925–2013