CVS update: samba/source/utils
Andrew Bartlett
abartlet at pcug.org.au
Sun Dec 30 18:10:03 GMT 2001
"Gerald (Jerry) Carter" wrote:
>
> On Sun, 30 Dec 2001, Simo Sorce wrote:
>
> > I tought we had changed this policy and voluntary set the uid in the
> > samdb ... ... it could be used by "admins who know what they are
> > doing"(TM) to set every user with a single uid and the likes in
> > future.
>
> We don't use it all. We were looking up in the samdb by uid, but then
> assigning to correct UID via sys_getpwnam(). This check made no real
> change in semantics (except less confusing).
The only problem I have with this whole change is the loss of the
pointers.
My concern is that we will have a user that doesn't have a uid (think
machine, etc) and we will initilise the struct with ZERO_STRUCT().
Those uid and gid fields now have a rather dangerous value, and I am
rather worried that we just might use them.
In particular, note that the auth subsystem uses a SAM_ACCOUNT to
describe a user. That initilisation is not always complete, and I
really don't want a stuffup like this. (I'm moving to modify the vuser
struct to contain the server_info as much of samba needs this
information later.
Now while I don't care how it is specified in the SAM_ACCOUNT, the
lookup/set functions need a way to say 'no value', because of the risks
involved.
I also want to be able to do a login without a getpwnam on the name at
all: This way we can handle the winbind case with much more grace: we
take the user and group RID/SID in the info3, ask winbind which UID/GID
they map to and set them in the SAM_ACCOUNT. At this point we have
everything we need to become the user, or to do a getpwuid() - which
don't involve crazy double lookups with and without the domain name...
Andrew Bartlett
--
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
More information about the samba-technical
mailing list