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

[Jeremy Allison]

Luke Kenneth Casson Leighton wrote:
> 
> a reminder: how do you distinguish between uids in a local /etc/passwd
> and a remote NIS db, when the implementation of getpwnam() / getpwuid()
> or equivalents is designed to hide exactly that from users?

You don't. That is the whole point of the POSIX scheme.

> scheme 1 is as i first answered: you have two SURS tables.  one is
> maintained manually by the administrator [the administrator also
> maintains the /etc/passwd entries, so why not add the extra burden
> of maintaining a SURS table, too? :]

Because it is an *extra* account databases.
Remember George Orwell,

1 account db good,
2 account db's bad...

:-).

> DOMAIN1\Administrator=root
> DOMAIN1\Support%2=is%2
> DOMAIN1\%1 = %1
> DOMAIN1\* = guest1
> DOMAIN1\* = guest2
> DOMAIN1\* = guest3
> DOMAIN2\Guest = guest4
> DOMAIN3\Guest = guest5
> DOMAIN3\Administrator = d3root
> DOMAIN3\%3 = d3%3

This is *hideous* (and completely opaque). I can't believe you're
seriously suggesting such a file. Why not go the whole hog and define
it as a perl or awk program !

> please think REALLY hard about why i might think that this is an
> unnecessary restriction.  please LOOK at the example unix password
> database i created, which has users d3root, d3doej and d3fred as REAL,
> LOCAL unix users - NOT remote users, because as i keep telling you i KNOW
> posix doesn't support the concept remote users, so i created three LOCAL
> ones instead!

This is where we disagree. However, I do agree that having
a .so mechanism is a good idea so that you can write whatever monstrosity
you want to map users and load it into Samba :-).

Just distribute it as an add-on package, that's all I ask :-).

Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------