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:
- controlling tty
- process groups
- session IDs (which are like groups of process groups)
These are 32-bit numbers. A bit too small, and cannot be changed
easily since they are tightly coupled with controlling ttys.
These are not part of cred_t. But PAG semantics require that the
process grouping scheme be part of cred_t.
- audit ID
These are available IFF auditing is enabled. Eventually they will be
available all the time.
And these are also 32-bit. And they are currently not visible
without privilege, though these two facts too might change in future
releases. This is part of cred_t.
- process contracts
Tightly coupled with SMF in the case of non-login session processes,
otherwise loosely coupled with ctrun(1) but potentially more tightly
coupled in the future if you think of something like MacOS X's
launchd. It is not possible to change a process' contract
membership. Also, this is not part of cred_t.
- project ID & task ID
This gets the closest to PAGs and exemplifies the real problem with
trying to reuse an existing process grouping scheme for PAGs.
Project IDs, which are allocated globally by the name service
backends, are part of cred_t, but task IDs, which are allocated on
demand (subject to resource limits) are not. This could be fixed, of
course, but to be clear: it's the task IDs that are the process
grouping scheme here, not project IDs.
Reusing task IDs for PAG-like uses would work, provided that one did
not set resource limits on how many task IDs a user could consume
(presumably one could limit a user to as many task IDs as processes)
and that we added a field to cred_t to carry the task ID.
But in the end the problem with reusing task IDs (or any other existing
process grouping) for this is that there are many uses for PAG-like
process grouping, and each use would need to be multiplexed atop a
single underlying process group scheme. Which means that any time a
user wants to run somehting like newtask(1), pagsh(1) (the AFS util),
etcetera, all those schemes multiplexed atop task IDs (or whatever)
would have to be coordinated since the underlying ID would change but
only for a specific purpose, but not the others.
Perhaps an example will help show the complexity of multiplexing PAGs
atop other things. Most of the rest of this reply will deal with such
an example.
Consider the following potential uses:
- controlling audio device (like controlling ttys)
- mech_krb5 credentials management
- mech_dh credentials management
- ssh agent
- AFS PAGs (which dovetail with mech_krb5 credentials management)
- other stuff
Now suppose that pam_unix_cred(5):pam_sm_setcred(3PAM) causes new login
sessions to be in some new process group atop which we multiplex the
five or more uses listed above.
And then suppose that the user wants to use a different set of SSH keys
in a "sub-session." In AFS parlance they'd run pagsh(1) to create a
process in a new session, much like newtask(1) in Solaris. And then
they'd associate the desired SSH credentials with that new session.
But the user only wanted different SSH keys in that new session, not
different Kerberos V, mech_dh, or whatever credentials, and certainly
not a different controlling audio device.
So what would the utility that creates a new session with different SSH
keys but same everything else have to do to pull that off? It would
have to:
a) know about all the other uses multiplexed atop a single process
grouping scheme;
b) know how to get a handle for the things associated with the current
session for every one of those uses;
c) it'd have to create a new session;
d) and then it'd have to ensure that all the old things associated with
the previous session are associated with the new one.
And it would have to be extensible, so that new uses of this process
grouping scheme could be multiplexed atop later.
So it would have to be a pluggable interface.
That's a lot of complexity.
Whereas having a small array in cred_t of pointers to per-use process
groups would be far simpler.
Also, I think it's important to note that 32-bits is too small for these
IDs. The primary problem is that it's easy to rollover and then one has
to prevent conflicts by searching the space of currently assigned IDs.
This problem goes away if one uses 64-bit IDs (which last ~585,000 years
at one new local ID per-microsecond).
Nico
--
