On Tue, Jan 20, 2009 at 09:08:22AM -0600, Nicolas Williams wrote:
> On Tue, Jan 20, 2009 at 12:21:51PM +0000, Darren J Moffat wrote:
> > For the sake of completeness can you explain why all the existing things
> > don't meet needs and can't be enhanced to do so. Specifically I'm
> > thinking of things like taskid and projid.
> >
> > [ I know we had this conversation before but I've forgotten some of it
> > and I'd like it put in the public archives of this thread anyway ].
>
> Yes, we have.
>
> Existing things that are somewhat like this:
I should add a few things.
1) I did do a design of a C API for user-land multiplexing multiple uses
atop a single kernel-land PAG-like concept.
It was awfully complex, mostly in that a user-land daemon was needed
to track all the associations. Compare that to simply keeping a
small array of PAGs in cred_t. Trade-off: a wee bit more space in
kernel-land[*] vs. a lot of complexity in user-land. The choice
should be obvious.
2) Other uses I forgot to mention include X11 display/Xauthority.
The ability to update an entire group of processes, representing a
session of sort, to refer to a different XDISPLAY/Xauthority, ssh
keys, krb5 ccache, default audio device, etcetera, with a single
command for each of those uses, that would be awesome.
[*] Per-PAG and per-cred_t space, not per-process, though users can
fork() bomb and then cause each process to drop basic privs
separately, which would cause as many cred_t instances as processes,
and if you let them, they could also create as many PAGs as they
have processes. But processes are much heavier-weight than cred_t
anyways, so as long as you're imposing resource controls to avoid
fork() bombs, then the added space burden is noise. If you're not
using resource controls then you have a fork() bomb potential
anyways, and once again the extra space consumption for PAGs is in
the noise.
Nico
--
