User data, become_root etc

[Michael Stockman]

Hello,

Michael Ju. Tokarev wrote:
> Michael Stockman wrote:
> > [...]
>
> 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).

Yes, but to explain myself, I was not trying to force anything on
anyone, regardless of the impression my previous letter might have
given. If, and that is if (JF seems to have something to say about
this), something ever in a far future come out of this, it will be a
compile time option for those who so desire, at least by my account.
For those who don't want it, I do intend to keep exactly the same
behaviour in samba as before (unless someone else changes it or I find
errors). Basically nothing should change for those who don't want it.

Your point about "serious" installs and other forms of databases I can
only agree with. My point was really to try to work something general
out for all those "special case" databases that samba contains *today*
(eg smbpasswd, wins, browse list, current connections and others that
either exist or should exist). My main target is the smbpasswd file,
that is a BIG pain under some circumstances, others are just bonus
points. If someone with the proper knowlege and equipment (not me,
that is) would like work on those "serious" install issues, that would
be great.

> > [...]

> 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...).

I agree that security is very important and difficult, the list makes
no claim to actually be in order of importance. It seems to me that
completely satisfactory support for at least some other databases is
difficult/impossible to achieve due to restrictions in authentication
etc. A custom database could possibly circumvent this and if
implemented properly provide more complete and secure services than
would be possible without modifications to other products.

If, once again, something comes out of this, I would of course it like
to begin purely as a skeleton which evolves, with the help of those
who knows more about this than I do.

> 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".

The point with replication in the database is to only implement one
protocol that can be used for whatever data we wish to replicate in
the database. If we get this to work, implementing all other
replication protocols (of interrest to samba) would only be necessary
to interact with other products.

Best regards
   Michael Stockman
   pgmtekn-micke at algonet.se

PS As you can see there are many ifs, coulds and mights. No promises,
that is.
Also JF and Jeremy seems to have discussed and discarded this idea
before, although I don't have any details yet. Until then I feel like
a database is good structure, although I know that structure is not
the most important part of the head branch.