samba 2.2.2, session userids, and hp-ux 11.00

[Frank Smith]

andrew, gerald,

i said:
> > > with samba 2.2.2 and hp-ux 11.00, i noticed that the smbd
> > > sessions retained the root userid, even though they created test files
> > > with the
> > > appropriate ownership:
> > >     root   641     1  0  Jan  7  ?         0:02 /usr/sbin/inetd
> > >     root  7749   641  0 02:08:35 ?         0:00 smbd
> > >     root  7747   641  1 02:08:18 ?         0:00 smbd
> > >     root  7751   641  0 02:08:49 ?         0:00 smbd
> > > btw- the smbd daemon is launched via inetd.
> > >
> > > user daemons running as root processes concern me because if/when someone
> > > cracks their samba daemon, they gain root access to my system.

gerald said:
> > smbd runs as root except when perform some operation on behalf
> > of the user.   This is by design.

problem is, these daemons WERE launched on behalf of the user.  they were NOT
launched as a smbd -D process.  each smbd process started after the user
performed a net use command on a nt box.  thus, i expected to see joe user's
userid rather than root.

andrew said:
> Its also a fairly recent change that both confuses admins and makes a
> quick 'who is that chewing my cpu' a little harder. 
> 
> That said, one smbd can serve any number of users, and often has to do
> things as root.  As such we now move back to root in our idle loop - I
> think we only did that as required in the past (meaning we ran as the
> user most of the time instead).

ummmm.  i was not aware that the samba daemons switched userids back and forth.
 this makes smbd daemons sound a lot more like nfsd daemons in terms of
behavior.  however, i thought nfs used udp while samba used tcp.  doesn't that
make it hard to switch from one smbd process to another?  i'm also still
concerned about what happens if someone cracks the smbd process (a'la buffer
overflow or something like it).

thank you, andrew.  your answer makes sense to me and matches my observations
of samba-2.2.2 behavior, even if it does raise other questions and issues.

frank smith
frank.smith at unilever.com