On Tue, 14 May 2002, Nicolas Williams wrote: > On Tue, May 14, 2002 at 11:23:15AM -0400, Sam Hartman wrote: [original context deleted as no longer relevant :-)] > Here I must repeat my mantra: it is worth following Windows in this > instance, like so: > > - processes should have an array of creds, much like they have array of > open files Yes! > - each thread (or cloned process) should have a "current cred_t" which > is used for permissions checking by all system calls / file systems Yes! > - creds should be an opaque-ish type like the BSD/Solaris cred_t, > but extensible and with each cred_t containing at most one of each > sub-cred type. > > Think of cred types such as: > > - POSIX (e.g., UID/GID, with effective and real for compatibility) > - capabilities > - Kerberos (as in a ccache name / open file, but not the actual tickets) > - SIDs (for Windows compatibility and because they are better than UIDs) > - etc... Yes! > - this would enable the emulation of the Windows user impersonation > system calls, which are much better and simpler to use that set*id() > > - this would allow multi-threaded processes that impersonate client users > > - SIDs really are superior to UIDs/GIDs - to begin with SIDs support a > hierarchical namespace, whereas UID/GIDs can only implement a flat > namespace This is one thing that Windows got right :-) > > Of course when you take things to their logical conclusion, PAM would > > be responsible both for the setuid call *and* initgroups; I think > > doing one without the other would be wrong. > > Yes, of course, though setuid() would be replaced with an > assume_given_cred_t()... > > > Getting to that ideal world would be very difficult; I think the PAM > > upstream, libc upstream and application writers would all disagree > > with us. We'd also need to think carefully about the API and > > potentially change things and better define things such that PAM could > > actually be responsible for user credential management. But hey if > > anyone ever wants to fight that battle, I'm certainly interested in > > helping. > > And I'm suggesting major surgery on the kernel-level process credentials > concept... Eerybody runs away from this. Well, Andrew Tridgell wants to push SIDs into the [Linux] kernel and I want to push them into FreeBSD, and indeed, the work being done in FreeBSD anticipates much of what you want, I think :-) Regards ----- Richard Sharpe, rsharpe@ns.aus.com, rsharpe@samba.org, sharpe@ethereal.com
