The Samba-Bugzilla – Bug 1037
the script of "add script user" run as "nobody"
Last modified: 2005-11-14 09:27:31 UTC
the script of "add script user" run as "nobody" (Slackware 9.1), when the
documentation says that it must run as root.
are you connected as root ? Doesn't sound like it. The script
runs under the context of the connected user.
No, I'm not connected as root, but the documentation explicitly says that the
script will run as root. Note that this is required because the functionality
of the script depends on that. Usually the "add script user" script will
change /etc/passwd to add the user, etc, and it must be done from an non-root
user connection but with the script running as root.
The add user script is used for 2 things.
(a) The samr_create_user call which is done under the
context of the connected user, and
(b) one behalf of a user when security = domain and
you are not running winbindd.
which case are you talking about ?
The (a) option can't be possible because the user doesn't exist in the
system yet (because that, the "add user script" must be runned).
I don't really understand you about (b), but i'm using security=user, so
probably is not my case, but note that the user also doesn't exist yet.
From the smb.conf manpage under the "add user script" section:
"This is the full pathname to a script that will be run AS ROOT by smbd(8)
under special circumstances described below."
"This option allows smbd to create the required UNIX users ON DEMAND when a
user accesses the Samba server."
Note, I found this bug using Samba 3.0.2rc2, I didn't checked again with
3.0.2, and now I'm using winbind, so this bug doesn't affect me anymore.
I've had the same problem on both 3.0.0 and 3.0.2
When creating a user calling the add user script via smb.conf from User
Manager, I get an access denied error.
Other scripts called from smb.conf seem to be working OK.
The log file shows the user being created and then immediately deleted, but no
changes to the passwd files, altough the same command string works fine from
It appears to a problem unlocking and writing to the passwd files, which would
happen if the script is executed from a non-root account.
I am connecting as root, which indicates to me the context of the connected
user is not the issue here, but who the script gets called as from the smbd.
closing out. If there is a problem specifically
with user manager support, plezse open a different bug. Thanks.