Security Identifier (SID) to User Identifier (uid) ResolutionSystem

[Luke Kenneth Casson Leighton]

On Wed, 29 Dec 1999, Jeremy Allison wrote:

> Luke Kenneth Casson Leighton wrote:
> > 
> > > If someone updates the NT account db, or the
> > > UNIX one, without editing this mapping file, the admin is
> > > hosed.
> > 
> > adding to the NT account db or the Unix one is fine.
> 
> No it isn't, because then the assumptions you have made
> (that the admin is all powerful and never makes mistakes)
> is *wrong*, and their system will be screwed.

what assumptions?  describe to me my assumptions.  in particular, read the
auto-pop section in draft-lkcl-sidtouid[pam-00.txt and the accompanying
post that outlines a detailed walk-through and an actual implementation of
an outo-pop algorithm, and then tell me about my assumptions.

 
> > as outlined in the opening paragraphs of the auto-population section,
> > which is why i propose auto-pop.
> 
> How do you fix drift. Your solution doesn't address this at
> all.


i was thinking about this one over the last few hours (i can't think in
days at the mmemnt!) - you just delete the table and let it get
repopulated with the auto-algorithms.

that's not an unreasonable thing, is it?  specify this in the README:

if every you cahnge a uid on a local system, in addition to having to
clear up the mess associated with re-chowning the old user's files to the
new user, you will have to do this:

rm /etc/surstable
 
> > ummm... not quite :)  you still need to choose a local POSIX uid/gid (i
> > take it you're talking about appliance mode, here), so you _still_ need a
> > SURS table.
> 
> No - you need a SURS *algorithm*, not a table. Tables get
> messed up and drift.

delete the damn things!, it gets populated with the new (non-drifted)
mappings!
 
> > weelll... it only has to be _+presented_ in NT-format, and the external
> > presentation is MSRPC, and we already have a 99% complete implemtation of
> > \PIPE\samr, so that's no problem: all we need now is a comprehensive
> > password db api im,plementation.
> 
> Yes. That's called winbind.

oh no.  please.  no.  you want me to call rpc_server/srv_samr.c
winbind???  no thanks.

> > > as MS don't release enough information to replace the
> > > authentication and authorization code on NT. On UNIX
> > > however, we have PAM (for replacable authentication)
> > > and nsswitch (for replacable authorization - ie. enumerating
> > > user and group lists).
> > 
> > i know enough about NT stuff to know what to do
> 
> Then I (and millions of NT users around the world) wish
> you would do it :-).

ok, it comes down to this.  i think it's perfectly acceptable to have Unix
servers to be part of arbitrary NT domains.  you, however, do not.

if you can accept that i can come up with something that fulfils my goal
to make Unix fully NT-domain interoperable (by definition making unix part
of arbitrary NT domains, under that unix admin's control, of course), then
i will go ahead and do it.

if you do not accept this, then i simply won't bother doing it, as i will
be wasting my time: i have other projects and sub-projects to consider,
and writing code that's not going to be accepted / used is not my idea of
fun.

for example. *still* sitting in the samba ftp is
samba-1.9.17-multi-wg.tar.gz

complete waste of time,_that_ was.  and what really bugs me is that roger
binn's vision fs team implemented a multi-workgeroup stuff, and now they
have full nt domain compatibility, too, and GUESS WHAT?  WE HAVEN'T!

[lots of people track the samba project, including the source code, by the
way. hi people!]

> > ok.  again, exactly the same problem applies to winbind as it does in
> > samba.
> > 
> > someone needs to make the decision about how to _create_ SIDs, and someone
> > else needs to make the decision about how to map SIDs to uids/gids.
> > 
> > the synthesis you describe above is one possible implementation.  that
> > implementation sufferws from exactly the same limitations that samba 2.0.x
> > has, because you are confusing (i think) the role of SID creation with
> > SID/uid mapping in exactly the same way for both samba 2.0.x and winbind.
> 
> It is one solution for winbind. Whoever writes the code gets to chose :-).
> 
> > oh no.  you thinjk that by creating winbind, we can optimise uids/gids /
> > RID lookups?
> > 
> > no.  please.  if you start thinking that's acceptable, you're _really_
> > going to mess this up and continue to argue with me about this.
> 
> Yes, it is acceptible. Yes, I do think this. This is why
> we're still arguing :-).

uh-oh.

it's a bit unfortunate that you are imposing limitations on what i
consider to be a hypothetical discussion.  no actual code written, and
your decision [that mapping unix systems to more than one NT domain, to
make things "simple"] has such far-reaching implications that it negates
any necessity for SURS tables in the first place!  [definition of surs
table:
o       Multiple copies of the same identical table, on multiple POSIX systems.
The means by which the table is copied to those systems, and kept up-to-date,
is an implementation-specific issue.
o       A single actual table, accessed remotely by multiple POSIX systems.
o       Identical automatic SURS table population algorithms in use on
multiple POSIX systems, the use of which MUST result in identical
entries in the SURS table used by each POSIX system.  Each table need not
be identical, just the entries in each table.
]

SURS tables are not even needed, under your scheme [with your decision /
hypothesis], because there is no _need_ to map between uids and SIDS,
because the entire thing is so limited and restricted [to one domain per
samba server] that you only really need to use usernames.

in other words, SURS tables take samba to the next level.  full nt domain
interoperability.  if you think that's too complex, then please stick to
working on the file serving portions of samba, and leave the nt domain
interoperability stuff to me.

please.

love,

luke