Bug 3538 - "add user script = /usr/sbin/useradd ..." run as nobody
Summary: "add user script = /usr/sbin/useradd ..." run as nobody
Status: RESOLVED INVALID
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.21a
Hardware: Other Windows XP
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-22 01:26 UTC by Bojo
Modified: 2019-02-16 17:33 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bojo 2006-02-22 01:26:51 UTC
Greetings!

I have the following configuration:

Two PDCs with Fedora Core 4: PDC1 and PDC2.

PDC1 trusts  PDC2, respectively PDC2 is trusted to PDC1.
I join an XP workstation to PDC2. After restart i can see both domains in the login screen domain combo box.
I can logon to PDC2 , but not to PDC1, since the PDC2's /etc/passwd lacks the username from PDC1 i am trying to log in with. To correct this i edit smb.conf adding this line:


add user script = /usr/sbin/useradd %u -g users -s /bin/false -d /dev/null

After another unsuccessful login to PDC1 (with username ivan for example) in the PDC2's log (/var/log/samba/winxp.log) can be seen the following lines:

useradd: unable to lock password file
useradd ....gave 1


When i try to access a share on PDC2 with a PDC1 user (ivan for example), useradd is executed successfully, and user ivan is added to /etc/passwd.

I found out that during login "add user script = /usr/sbin/useradd %u ......" is executed with user nobody, and this user has no right to execute useradd, hence an error occurs.

After that i added user nobody in the /etc/sudoers so he could execute sudo on PDC2:

visudo -f sudoers
%nobody  ALL=/usr/sbin/useradd

And edited smb.conf on PDC2 like this:

add user script = sudo -u root /usr/sbin/useradd %u ......


Now the logging to PDC1 works fine, but this is not normal, maybe it's a big security hole!

My question is:
Is this a bug in samba, why when mapping a drive useradd runs as root (as described in the samba manual), but when logging, it runs as user nobody who has no right to execute useradd?

If am wrong - correct me, or point me to another solution, I don't want use winbind.

Thanks in advance :-)
Comment 1 Gerald (Jerry) Carter (dead mail address) 2006-02-22 08:26:45 UTC
The best solution is to run winbindd on a DC to handle the 
trusted users and groups.  Why don't you want to run winbindd?
Comment 2 Bojo 2006-02-23 01:42:35 UTC
(In reply to comment #1)
> The best solution is to run winbindd on a DC to handle the 
> trusted users and groups.  Why don't you want to run winbindd?
> 

Why..?
Well, because I don't want complicate matters with a winbind...
Maybe is it the best solution, but I think myself that is too difficult, too many problems, errors and etc...! I read about winbind and tried it, but without success, example problems as:

wbinfo -u/g 
"Error looking up domain users"
and etc..
I don't know, what when and where must do it ?, I'm already confused

"add user script" run as nobody - Will be fixed this bug in future?
I thing if this bug fixed, that solution will be the best!!!
Comment 3 Carsten Dumke 2009-05-27 03:51:07 UTC
(In reply to comment #2)
[...]
> wbinfo -u/g 
> "Error looking up domain users"
> and etc..
> I don't know, what when and where must do it ?, I'm already confused
> 

Has the server running winbindd joined its own domain?
"wbinfo -t" should return "checking the trust secret via RPC calls succeeded"
in this case.

I had the same problem (see bug #2282) and the winbind-solution works here.

Comment 4 Björn Jacke 2019-02-16 17:33:53 UTC
comment #1 said it. Any other attempt to do this is wrong.