Alexander Viro writes:
> On Mon, 28 Aug 2000, Albert D. Cahalan wrote:
>> a. The shared VM changes. If it hurts, don't do that. No bloat here.
>> b. All other threads get killed. This is POSIX-friendly.
>> c. Force an unclone(~0) to go with the exec. Can do setuid CGI.
>>
>> Doing unclone(CLONE_MM) is lame. Unclone all or none.
>
> Screw POSIX, but why do you want to unclone everything? Components are
> independent. Really. I can see the point in unclone(CLONE_FILES) _if_
> there was close-on-exec.
That's one special case.
> I can see the point in unclone(CLONE_FS) upon
> personality change (had to do that during the namei rewrite - alternative
> root depends on personality and it's clearly a part of fs_struct). But
That's a second special case.
> what, in the name of Cthulhu, makes us unclone() everything, no matter
> whether we need it or not?
Setuid is a third special case. What happened to good taste? :-)
> E.g. would you really want to get an
> independent namespace upon exec()? Goodby mount(8)...
The namespace bit is a backwards bit, so it can be kept.
This is a wart that must appear everywhere CLONE_* does.
The pre-existing UNIX cruft is something you have to live with.
You didn't make fork() unshare namespaces.
BTW, mount(8) is going to need some serious hackery already,
just because admins will demand global (all namespace) mounting.
Under plan c, an exec should make the world look pretty much as
if the last clone was a fork(). This is great for the CGI example.
Imagine documenting partial unclone. "... except that a CLONE_FILES
relationship is broken when there are close-on-exec file descriptors,
a CLONE_FS relationship is broken if loading the new executable
causes a personality change ... error may be occur iff a task tries
to execute privileged code (setuid, setgid, set-capability-bit, or
unreadable executable) while party to a thread construct involving
CLONE_FS, CLONE_FILES, CLONE_THREAD, CLONE_PTRACE, CLONE_PARENT, or
certain yet-to-be-defined future clone() flags ..."
That doesn't taste good at all. Plan 'a' is OK, plan 'b' is just
barely edible, and plan 'c' is quite tasty.
-
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:22 EST