FW: Speed comp. TNG & 2.2.alpha (fwd)

[Luke Kenneth Casson Leighton]

it just occurred to me last night, that this is a complete red herring.

should really write this up as a white paper.

the whole concept of trying to present unix groups as nt groups is a nasty
hack.  i did it as an exercise to understand what was going on.

it combines three principles into one mess:

- map username (and map groupname)

- SURS.

- a SAM database.

using these, e.g. there is an implementation of SURS in winbind, you solve
the problem.

what needs to be done:

1) write a complete SAM database implementation.  *IGNORE* unix *TOTALLY*
when doing this.  no getpwnam, no getgrnam, no getgroups, it has xxxx-all
to do with a SAM database

2) write a good SURS implementation.  *NOT* the proposals that are
floating around that think it's okay to have one-to-many SID<->uid
mappings and one-to-many SID<->gid mappings.

3) use map username and re-implement map groupname (map groupname isn't
used in samba)

now, if you need to make decisions about private groups, about which group
names to ignore, etc, that is done in the SURS implementation.

a good SURS implementation is to use the same principles that exist in
nsswitch, but to add root-only "add new entry" functions.  i.e. a series
of four set and get functions, sidtouid, uidtosid, sidtogid, gidtosid get
and set (root-only on the set), and to have dynamically-named modules in
an /etc/sursswitch.conf

the current implementation of SURS, which is a good one for appliance-mode
type systems where you don't have to worry about users/groups from a unix
view-point quite as much, can be split into a module libsurswinbind.so and
referenced in /etc/sursswitch.conf.

then, if anyone wants to write a SURS module that deals with private
groups, they can.

if someone wants to write a networked SURS module with a cacheing
back-end, they can.

if someone wants to write a special module that chews dogfood and whistles
the theme tune to 'annie, get your gun', they can [a reference to an entry
in the samba survey, from over 4 years ago, if anyone's wondering!!!! :)
:)]

etc.

dr andrew tridgell has agreed with this idea in principle, except he
thinks that it would be better to contact the people who are responsible
for nsswitch and get them to add the two sets of four get and set
functions to nsswitch, which would imply that everyone would need to
upgrade their version of nsswitch for this to work.


so, essentially, worrying about what method to add to get an experimental
learning-curve hack to work less badly is throwing good money after bad.

do a proper job, as outlined above, it will save time _and_ be more
flexible.

luke

 ----- Luke Kenneth Casson Leighton <lkcl at samba-tng.org> -----

"i want a world of dreams, run by near-sighted visionaries"
"good.  that's them sorted out.  now, on _this_ world..."


On Wed, 28 Feb 2001, Peter Samuelson wrote:

> 
>   [me]
> > > This whole thing needs caching -- the above sounds like a lot of
> > > overhead.
> 
> [Steve Langasek]
> > That sounds like over-engineering to me.
> 
> True.  If the caching needs to be done it can be done at the libc
> level, which I think already happens on many Unices.
> 
> > How do you decide generally which group names should be ignored?  I
> > can certainly think of cases where I might have a file whose gid maps
> > to a group that conflicts with a username and I /do/ want to show the
> > group in the file permissions...
> 
> That's a very good point.
> 
> Peter
> 
> 
>