[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: sufficient account management checking for locally defined users



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []