Alexander Viro writes:
> On Tue, 29 Aug 2000, Albert D. Cahalan wrote:
[interaction w/ setuid, close-on-exec, and personality pseudo-roots]
> We _have_ this interaction. In case you've missed it, sys_personality()
> that really happens to change personality unshares fs_struct. Has to.
> Rule: you do crap, _you_ pay with inconveniences. Point-blank restriction
> of sharing anything to the beasts that run the same binary is *CRAP*.
BTW, I've yet to see a good use for all-but-VM sharing after exec.
Unsharing everything in the exec lets one avoid a system call.
Unsharing nothing makes exec smaller and faster.
> Same
> moronic "it's a part of process" approach. Totally unjustified in case
> of Linux, because here thread == process. Get over the POSIX model.
I'm very much not obsessed with kernel-enforced POSIX,
but it is good to reduce the hoops glibc has to jump through.
Reality involves getting pthreads to be half-way fast.
If a pthread_exec() system call would really help, why not?
As a separate system call it shouldn't be too offensive.
> VM is
> just one of the resources. There are legitimate uses for sharing between
> different programs. Your proposal prohibits them.
Proposal 'c' is that way. If you agree that "VM is just one of
the resources" but think that there are "uses for sharing between
different programs", proposal 'a' is for you.
Want to unshare VM? Do it, with the new unshare() call.
Want rope to hang yourself? Do an exec while multiple
threads are running, most of which will crash when the VM
changes right under them. If a close-on-exec shared with
the child would hurt, Don't Do That. Personalities make
life fun when you randomly exec unknown executables into
your thread group.
This is clean and fast. Only the setuid wart needs to
be handled. All the other kernel bloat just goes away.
>> The explanation still sucks quite severely. The personality and setuid
>> problems are particulary gross, because they depend on what executable
>> is being started. Behavior changes drasticly when one merely
>> recompiles with an alternate personality.
>
> Which is kinda the point of personality, no?
Sure, but normally this disease only afflicts one task.
With the personality code doing an unshare, there is no
way for the original thread group to know what will remain
shared after the exec.
For an app, getting back an error code may be most desirable.
(not saying the implementation would be trivial)
>> If you simply unshare on exec, all this special-case crap goes away.
>> The "kill other threads" option also has this nice property, and the
>> "let user shoot foot" option only suffers from the setuid wart.
>
> Look: your sematics can be trivially achieved with the
> share-whatever-we-can one. Noting could be easier,
> unshare(CLONE_ALL);
> execve(...);
> and that's it - precisely what were asking for, unambiguous,
> works regardless of the execve() details. Now, try to get the
> other way round. Can't do it.
Hey, that works for the VM too. An "unshare if you like" policy
lets one have plenty of clean and fast rope.
> "If we shove this box into the car half of us will have to take
> the bus" is fine and sane.
> "... so let's make everyone always take the bus" is straight from
> the Dilbert-land.
Fine, plan 'a' then: "If you are stupid enough to pack a full
load of people into a car that is already half full, some of
the people might get injured or killed. Don't do that."
Either plan will reduce the special-case crap. The POSIX way
also works, if you're into that sort of thing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:24 EST