VB: become_root remove patches (head)
pgmtekn at algonet.se
Thu Aug 19 05:43:48 GMT 1999
> > > > Actually I could hardly care less for 2.0.X. However lkcl
> > me neither, however my pre-alpha code got chucked into a release
> > about eight months ago and this is one of the issues: anonymous
> users can
> > enumerate users using USRMGR.EXE or rpcclient.
> > > > to my interpretation) asked for it in a previous mail.
> > .. so i figured it's kinda a good idea to care about this sort of
> > so mentioned it to you, michael, as you were going over cvs main
> > > > Still, I did ask for specific reasons why become_root exists
> > > > samba changes uid during run-time. The contest is still open
> > > no
> > > > prize :-). Well, actually you could win some respect for
> > > > caring about this.
> > ok. you _could_ get away with splitting the passwords out of
> > private/smbpasswd into:
> > private/DOMAIN.user1 owner user1 -rw-------
> > private/DOMAIN.user2 owner user2 -rw-------
> > ..
> > and then individual users could change their own passwords. they
> > also, unfortunately, _delete_ their own passwords by logging in to
> > samba server, cd private/, del DOMAIN.user1 oops! i can't log in
> > *dur* :-)
> > only root would be allowed to enumerate private/smbpasswd.* and
> > passwords.
> > in fact, we already _have_ the base-level functionality to do
> > in private/smbpassfile.c, it currently generates .mac files.
> Well, I think I have differed between samba's right to privileged
> information (for internal purposes) and actually sending to the
> client, which is very much different.
> One could imagine a shadow like system with a world readable or
> readable smbpasswd (allowing anyone/some to enumerate) and a root
> readable smbpasswd- with the password hashes in. This would give the
> administrator control over who can enumerate and who cannot, while
> samba can still can access everything as root.
> > > > > This function is needed in many places to take on root
> > > > > authority whilst doing something and then call
> > > > > to relinquish it again (eg. scanning the smbpasswd file).
> > > >
> > > > This function is seriously missused (in head branch) to bypass
> > > > filesystem security.
> > yep. and 2.0.x.
> > > Samba is evidently giving out information that
> > > > the user doesn't have access to (through becoming root in the
> > > > stuff). I suppose we all agree that samba must never send
> > > information
> > > > obtained whilst being root, rather than the user, to the
> > um... well... it depends on whether you want full NT-like
> functionality or
> > not!
> If the choice is completely NT-like or security as set by the admin,
> think we should allow the administrator to set the policy. We should
> be able to make something up that allows completely NT-like
> functionality, while not breaking unix security (remember to differ
> between giving info to samba and to the user).
> > > > I know head isn't considered stable, but I can see no reason
> > > > whatsoever that we should save known errors in it (especially
> > > > security sensitive such).
> > true. i wasn't expecting you to remove _all_ calls to
> > become_root(), just the ones in rpc_server*/*.c, passgrp/*.c and
> > passdb/*.c!
> Well, nothing has been committed yet I trust. I actually don't think
> we have to remove _every_ call to become_root (I missed this
> limitation in your mail, I must admit). Password changing I would
> count as internal use.
> rpc_server/*.c patches you've got, if changeing this doesn't break
> something that should work. The others I don't think contain any
> become_root since I grep'ed for become_root in source/*/*.c.
> Best regards
> Michael Stockman
> pgmtekn-micke at algonet.se
More information about the samba-technical