UNIX->smbpasswd synch

Peter Samuelson peter at cadcamlab.org
Sat Jun 17 23:21:56 GMT 2000

[Alec B. Plumb <alec at etherwalker.com>]
> Your pam_pwexport.so module looks like a great idea, so I tried it
> out, using your shell script from the readme file. However, each time
> I tried to change a password I would get this message:
>     smbpasswd must *NOT* be setuid root.

Yeah, Douglas Irvine reported this already.  It appears that smbpasswd
is greatly bothered by running with (euid==0 && ruid!=0), which
generally indicates that the binary is setuid root.  Whoever put that
warning into the smbpasswd program did it for a reason: smbpasswd
should not be setuid root, indeed.

In this case smbpasswd isn't setuid root -- but the `passwd' program
is, and smbpasswd is inheriting those permissions.

I told Douglas to work around this with `su {user} -c ...', because the
`su' program sets both the real and effective UIDs to whatever they
need to be.

> It would seem like a good idea to run the external shell script as an
> untrusted user in any case.

I opted not to do this because it takes away flexibility.  My module
was designed to allow other password-changing mechanisms, including the
case of `smbpasswd' changing the local Samba password file, without
access to the user's old password.  (I.e. from `login' or `ssh', not
from `passwd'.)  In that case it *does* need to run as root.

At some point I may add an option to the module to run as a particular
user, or as the user whose password is being changed.

[douglas irvine <dci at pitt.edu>]
> Now it is complaining "standard in must be a tty" as the error output
> from the su command run from the pam_pwexport executed script.

Annoying indeed.  Tests so far indicate that Linux `su' behaves rather
strangely.  If it has a controlling tty, it wants this to be stdin,
even when run as root (so it doesn't need to prompt for a password).
If it has *no* controlling tty (i.e. run from `at'), it doesn't
complain.  This is all empyrical, since it doesn't seem to be
documented and I haven't looked at the source yet.

A controlling tty, like a stray dog, is not always easy to get rid of.
My APUE is elsewhere at the moment, but if I remember correctly, the
portable method involves closing any file descriptor that might have a
tty on it, then forking and being the child.  Some Unices may have a
fcntl to accomplish the same thing, but I don't think so.

I am continuing to experiment to see if I can get `su' and `smbpasswd'
to behave simultaneously on this thing.  I have a couple ideas, from
different angles.  More in a bit.


More information about the samba-ntdom mailing list