How the heck can it work?
rcalex at home.com
Mon Jul 24 23:42:32 GMT 2000
Under VOS, inetd is initially started by the Overseer. I do not know what
it's UID,GID is. Since there is a root.root user, I would assume that
Overseer is NOT 0,0 superuser.
It is not uncommon to stop and start the inetd process for testing reasons.
VOS does not have a kill SIGHUP (yet) to cause the inetd.conf to be re-read.
I just ran a test, and if I run inetd as root, I get full swat access. If I
run inetd as another user, then my swat access is determined by the perms on
From: James Sutherland [mailto:jas88 at cam.ac.uk]
Sent: July 24, 2000 5:24 PM
To: Ron Alexander
Cc: Gerald Carter; Samba-Technical
Subject: RE: How the heck can it work?
On Mon, 24 Jul 2000, Ron Alexander wrote:
> I just discovered part of the problem. What I have been trying to do all
> now is to RESTRICT swat so only the root user could modify the smb.conf
> file. The mistake I made was to start inetd as root. This somehow gave
> different rights (I suspect real UID vs EUID).
Sounds like your inetd is very different from Unix, then. Under Unix,
inetd runs as root
When a connection arrives, inetd will fork a new process, which sets UID
to that specified for this port in inetd.conf, then execs the appropriate
This file is then run as the specified user from inetd.conf. Setting it to
be SUID will give it an EUID of the file owner, keeping a UID as specified
> To answer your question, if I SUID the swat pgm, I see the start and stop
> buttons on the status page.
> Here is the problem. I do NOT get a login screen for swat since I have to
> run it in -a mode. The reason I have to do that, is that the encrypted
> password is NOT returned in the pwnam structure. This is an extension to
> POSIX and we have decided not to implement it since many of our *nix
> are starting to toe the POSIX line.
> My understanding is that I lose the password maintenance screen of swat if
> use -a mode. I can live with that for now.
> I assume therefore that I must be running as root group root and the 640
> perms on the smb.conf file are controlling the behavior.
> At this point, I can either give everyone the ability to look at the main
> page and view the config, or only allow the root user full access and
> everyone else no access.
OK, long term solution: patch swat to handle password properly on VOS. How
are they stored - shadow-file or similar?? Or is there an API call to
retrieve it for a given user?
More information about the samba-technical