svn commit: samba r13017 - in trunk/source: lib utils

Volker Lendecke Volker.Lendecke at SerNet.DE
Thu Jan 19 08:52:14 GMT 2006

On Thu, Jan 19, 2006 at 02:19:51AM -0600, Gerald (Jerry) Carter wrote:
> I'm more concerned about you.  Only that I don't want you to have
> any code tossed aside.  If smbd will not authenticate root, then 'net
> sam rights' on masks the problem.

The alternative I thought about was to have something like ldapi. This would
excercise the existing code paths a lot more. Or rely on Kerberos, but this
from my point of view is not simple enough.

Don't get me wrong, I'm fine with dumping all of net_sam, it was just an
excercise that I did sitting in a hotel...

I do think however that net groupmap and pdbedit both need severe cleanup.
pdbedit just ran out of bits, we can't add more fields for editing anymore.
This is something I can hardly accept.

The main problem with net groupmap is not the interface as such, the problem is
that it is way too easy to screw up the group database by just adding mappings
for existing SIDs and/or gids. Or add stuff for unknown domain SIDs that then
later on might make pdb find stuff it should query from winbind and so on.
Sure, we can add all sorts of checks to it, but I think that now that we have a
reasonable (I hope) implementation of domain groups and aliases we know much
better what can and should go into the group mapping db. So I think a "new"
tool might be appropriate.

Apart from that, back to "net sam rights". I think it's a bit difficult
conceptually to have parts of our database only accessible via rpc. If we went
down that path fully we could also dump pdbedit, smbpasswd and 'net groupmap'.
I know I'm exaggerating it a bit now, but it's hard to explain that parts of
our "SAM" can be looked at directly and parts of it need a running smbd. Where
do we draw the line?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the samba-technical mailing list