On Tue, 29 Aug 2000, Albert D. Cahalan wrote:
> > Erm?
> > * setuid is a fscking wart - THE mistake of dmr and/or ken.
>
> If not urban legend, dmr was the patent owner.
Erm... That would be a nice way to bury one's mistake - patent it and
refuse to license ;-) Unfortunately, didn't happen...
> > * close-on-exec originated as a covenience hack mostly to make
> ...
> > * pseudo-roots are _WAY_ past the fscking wart level. Terminal
>
> Yep, now why do you like behavior that interacts with
> all three? This is some sort of S&M problem you have?
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*. Same
moronic "it's a part of process" approach. Totally unjustified in case
of Linux, because here thread == process. Get over the POSIX model. VM is
just one of the resources. There are legitimate uses for sharing between
different programs. Your proposal prohibits them. For no good reason
other than presence of ugly hacks that make sharing impossible in case
of programs using these hacks. Well, duh. You use setuid - you don't get
sharing.
> >> BTW, mount(8) is going to need some serious hackery already,
> >> just because admins will demand global (all namespace) mounting.
> >
> > Umm.. I'm afraid that you do not realize what you are talking
> > about. Just think what mount(8) would do if it got a private
> > namespace. Right, modify it. Then what? Right, exit(2).
>
> Um, the point is you break mount(8) just by adding namespaces.
> The /var/mail filesystem dies, so the admin unmounts it and
> mounts a new disk... all the users, in login-enforced namespaces,
> continue to see the corrupt filesystem.
And if they run a MUA that happens to keep the mailbox opened they also
have a problem. The same one. _If_ we move to setups when all users have
private namespaces - fine, but then MUA accessing /var/spool/mail is an
idiotic solution. Why? Because there's nothing to stop you from mounting
mailfs on /var/spool/mail. Yes, userland filesystem. Served by process
that knows how to lock files, how to speak IMAP, POP3, etc. That process
(and it alone) has to care about getting access to physical mailbox,
whatever place/format it is in and playing nice with mail delivery agents.
All existing MUAs are working _and_ you can drop tons of crap from them.
That process would run in original namespace, BTW, and have enough clue to
leave the mailbox alone when it doesn't need the thing. End of the
problems.
Yes, there are cases when forcible umount from all namespaces is needed,
but that's not different from the problems that happen when your NFS
server goes south and you have to deal with clients. Nothing new here.
> So you need some hackery to make mount(8) cause change in all
> namespaces at once. Whatever is done, this will be gross.
> I suppose you'd require a loopback of some sort, so that one
> might rip the real filesystem out from under /var/mail instead
> of trying to unmount it in 50 different namespaces... ugh.
Not. Loopback would be gross, but I'm not proposing it. OTOH, getting all
mailreaders work with IMAP with _no_ changes in said mailreaders is a
Good Thing(tm). So is free (for mailreaders) support of any weird
protocol, format and location of mailbox, locking scheme, etc. - do it in
one place and that's it. Everything looks like we have the mailbox in
fixed format on local filesystem, no matter WTF is actually out there.
And guess what? It doesn't have to be one process and it's nowhere near
the kernel mode, or even suid.
> 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?
> 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. Compare "you can't share descriptors with suid, execve() will
forcibly unshare them" with "you can't share decriptors with execve()
because that's impossible for suid programs". See the difference? You
should care about suid semantics _only_ if suid programs enter the game.
Ditto for personalities, etc.
"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.
-
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 : Tue Aug 29 2000 - 03:23:44 EDT