I have noticed that with the net command it is not possible anymore to run 'net ads join' as non-root. With 4.4.x this still worked. What we do is to run it like this as user apache on a webserver (/tmp/samba contains a copy of /var/lib/samba, ownership changed to apache:apache):
KRB5_KTNAME=FILE:/tmp/samba/keytab net '--option=cache directory=/tmp/samba' '--option=lock directory=/tmp/samba/lock' '--option=state directory=/tmp/samba' '--option=private dir=/tmp/samba/private' '--option=smb passwd file=/tmp/samba/private/smbpasswd' '--option=debug level=99' ads join
It fails with this error message:
directory_create_or_exist_strict: invalid ownership on directory /tmp/samba/lock/msg.lock
messaging_init_internal: Could not create lock directory: No such file or directory
main: Unable to initialize messaging context. Must be root to do that.
Again, /tmp/samba/lock/msg.lock is owned by apache and has mode 0755.
The root cause seems to be that in source3/utils/net.c the call to sec_init() comes after the call to messaging_init_client(). The later calls sec_initial_uid() which at that time returns a non-initialized
initial_uid that just happens to be 0.
This means that directory_create_or_exist_strict() wrongfully checks if /tmp/samba/lock/msg.lock belongs to 0 (root) instead of the user running the net command.
This bug has been open/new for a while now. Any chance that someone will have a look at this?
The biggest issue will be ensuring that the reverse still works, that tools that normally run as non-root in a normal install don't start failing.
The other way to address it might be to work out why we require messaging in this join codepath.
Currently you rely on an uninitialized variable to be 0. I am no expert but logically this section in source3/utils/net.c
/* this makes sure that when we do things like call scripts,
that it won't assert because we are not root */
should be moved right before this one:
status = messaging_init_client(c,
I will add a patch against the git master of net.c.
Created attachment 13746 [details]
Any news on this?
I have a similar report for smbtree in Debian (https://bugs.debian.org/926474)
(In reply to Mathieu Parent from comment #5)
This report and the Debian report, look same but the Debian bugreport shows a Dolphin (KDE) smblcient protocol mismatch.
Dolphin still uses client max protocol = NT1