Status of Kerberos Support across Samba versions

[Nicolas Williams]

Phil, 

I hope you don't mind my posting this to samba-technical...

On Sat, May 06, 2000 at 01:47:00PM +0100, Phil Mayers wrote:
> <Sigh>
> 
> I just typed a huge email covering my reply, but Netscape decided the
> server had disconnected, *AND* it was going to just close the mail
> window without saving to Drafts or somesuch. Grr...
> 

Hee.

> Anyway, I did quote my own email accidentally.
> 
> MIT can, should and probably will implement an Open Standard, but I
> don't think MS will; They'll claim that they can't for "technical
> limitations in the current standard", which is a pretty normal tactic
> for them - commoditising protocols...

Right. But if we extend the standard through the standards process in
such a way as to achieve every technical thing that MS wanted to
achieve with their extension, then the pressure on MS to dump their
spec for the new standard will be hard to resist.

> I agree that knowing the SIDs does you no good unless you are doing
> something with them. I think mapping them to Posix GIDs is the simplest
> and cleanest approach (using SURS or such). Looking up the same data by
> name would make no visible difference to the user.

:)

> As for the kernel support...
> 
> I've been looking at this on and off for the past few months. I
> envisaged something like this (sighs, typing out pseudocode for the
> second time...)

So have I and others. Look at samba-technical archives around just
before 1/1/2000.

Remember, most modern Unix kernels (*BSD, Solaris) (Linux?) already
store POSIX creds in a fairly opaque cred_t struct type and provide
utility functions for comparing uid_t and gid_t values to a given cred_t
value.

So it should be possible to re-shape the cred kernel struct to be
extensible, e.g., to support multipe credential types, without having to
re-write any or much existing FS driver code.

Then all you need is an API like yours. The credential-setting API
should accept an optional token which the per-type credential "driver"
could require and/or check for validity. So you'll need an internal API
for each credential driver to export to the kernel.

You'll also need to deal with the Unix real vs. effective credential
model. That is, it would be nice to have a real vs. effective SID/RID :)
and it would be nice to have setsidrid bits in permissions masks on
files.

To begin with this would be used for the NTFS driver, and so there would
be no support for setsidrid permissions as the concept doesn't exist in
NT-land.


> Cheers,
> Phil
> 

At some point this idea will have to be broached to the various kernel
(Linux, BSD) mailing lists...

Frankly, I really like the NT domain SID + entity RID model. It leads to
irresistible features which are particularly desirable in the context of
organization mergers.

Nico
--