User data, become_root etc

[Michael Ju. Tokarev]

Michael Stockman wrote:
> 
> Hello,
> 
> After the become_root discussion a while back, I've been reading up on
> databases. I'm thinking that it might be a good idea to include some
> simple but more general database facility in samba (sdbd, Samba
> DataBase Daemon), to store user data in.
> 
> The advantages of this would be:
> * facilitate future expansion
> * reduce risks of simultaneous use
> * possibly simplify the main applications (smbd/nmbd) through lifting data
>   managing tasks into an own application that has great potential to
>   become very reliable.
> * possibly reduce security risks in smbd (move them to sdbd).
> * if we make the database connectable via ip, multiple samba servers could
>   act on the same user db, without requiring third party products
>   (LDAP/NIS etc, for the more amitious these will still be available).
>   There are also many many other gains with this approach and future
>   functionality in samba.

But maybe use different approach here? At least if underlying system support
that "third-party" products that are in that case "first-party", while samba
is third-party? E.g. if network already managed by some sort of nis/ldap
product, it will be painful to support another method of storing user data
at least... And, again, more and more modern systems already used a pam
mechanism (consider at least "all leading systems" for intel -- solaris,
linux and bsd), it will be a double-pain.
I think that it should be possible to allow some "pluggable" mechanism
for this purpose, maybe even "auth/db modules" (this requires rewriting
of passwd/wins/... etc stuff a bit, but this is present in all cases),
and make ability to use _existing_ approaches first and "private" as a
last resort. Yes, for simple installs it will be less useful, especially
for newbies, -- e.g. where I should search for user password!? -- , but
most "serious" installs it seems to be more "right" from my point.
Imagine at least a large organization served by some samba servers --
this is a pain in the ass to manage smbpasswd files, but yes, it is
more easily to have some central place to have as sdbd can make, but
that users should already used some nis/... processes; and them can
use different auth scheme -- mysql database for example (large
smbpasswd/passwd/shadow/... file is a trouble with a lot of accounts).

> * if we design in replication in this from the beginning, both wins
>   and sam replication (samba style) would be a snap
> 
> Disadvantages:
> * Access times may increase(?). This ought to be neglictible if the
>   smbd/nmbd and sdbd are running on the same server. Some caching in the
>   database access routines might make this neglectible in other cases too.
> * A new application will be created with many new problems during it's
>   evolution. These are probably only transient.
> * sdbd will need to be secure too (yet another security hasard),
>   especially if we choose to allow access from network interfaces.
> 
> >From my point of view the advantages are elephantous :-) compared to
> the disadvantages, and I will give it a shot, unless someone send me a
[]

I think that the "best" approach is to make all passwd/wins/sam routines
more "clean" so that other auth/db schemes can be added easily (maybe
like array of "maps" as in e.g. sendmail) by patching code, and we can
make such sdbd daemon as an addon for samba (at least configurable at
compile time option). But third disadvantage (security) is a very hard
thing, and I think that it should come first. And we can't forgot about
existing (widely used) services, support for them are very primitive
(at least from user's view) -- pam is an example (but I can't see if
it can be made more complete, for example -- password changing with
cleartext pwd, pam's (text) messages, etc etc -- I'm not an expert
here...).

And another "interesting point" -- for wins replication -- maybe wrote
new "WRTP" -- Wins Replication Transfer Protocol? ;)
There are many protos for similar tasks in other protocols (not only smb,
and not only for tcp/ip -- ipx itself "replicates" node names in the net).
And MS$ already used some mechanism for that (atleast for sam) -- why
not to use it (it may be served by sdbd and/or other ?mbd...) -- this is
not related to sdbd itself, only for it's implementation "details".

> Best regards
>   Michael Stockman
>   pgmtekn-micke at algonet.se

Regards,
  Michael.