Messages in this thread |  | | From | "Albert D. Cahalan" <> | Subject | Re: SCO: "thread creation is about a thousand times faster than on | Date | Mon, 28 Aug 2000 23:08:20 -0400 (EDT) |
| |
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/
|  |