SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts

[Luke Kenneth Casson Leighton]

On Wed, 9 Feb 2000, James Sutherland wrote:

> On Thu, 10 Feb 2000, Luke Kenneth Casson Leighton wrote:
> 
> > > Worse than useless, IMO - you do NOT want users to have access to the
> > > FILE, only (some of) the contents - and only when accessed via RPC, NOT
> > > when access as files...
> > 
> > so you want /etc/passwd to be made root-only access, right, on all UNIX
> > systems across the world, right?
> > 
> 
> No. Do you want /etc/shadow world-WRITABLE, so users can change their
> passwords? Or create a couple of files PER USER? Neither seems like a very
> good idea.

i will be either creating a SYSKEY-like algorithm (and to hell with anyone
who thinks it's an implementation of microsoft's reasons why syskey is
used, that's NOT why i need it)

or creating an equivalent of /etc/shadow

or just giving up because i'm fed up with having to explain things in such
detail when  it hurt like hell to just damn well type.

or just not explaining it, just getting on with it.
 
> More to the point, the SAM permissions do not correspond to file
> permissions.

yeah?  and??  so my job is made easier by mapping to the best
unix-file-sec i can and special-casing everything else.

and?? what's the problem?


> OK, you could split user attributes up into three categories
> (things they can change, things they can read, and things they cannot
> access at all), and then have three files per user (YUK) - or just do it

actually, i will need two per user (passwords and everything-else).

and you need... so far, i count about 16 separate single-key databases to
hold a full SAM database implementation.

that's if you don't go for a file-per-user, file-per-group,
file-per-alias, file-per-user-members, file-per-group-members,
file-per-alias-members system

which i'm considereing

in which case, you have to hold these in directories else it's a mess.

see HKLM\SAM\... for details.

> the normal Unix way, and have the file accessable directly only by the
> daemon, which then performs its own access control.
>

right now, i don't want to have to do that.