[Pkg-shadow-devel] --root option in upstream shadow

[Nicolas François]

Hi,

On Mon, Oct 24, 2011 at 01:06:11AM +0100, julian.pidancet at gmail.com wrote:
> On Sat, Oct 22, 2011 at 12:54 PM, Nicolas François
> <nicolas.francois at centraliens.net> wrote:
> >
> > What is the expected behavior when the utility authenticates the caller?
> >  1] authenticate the caller in the caller's chroot
> >  2] authenticate the caller in the target's chroot
> >  3] both
> >
> > I currently think that 3] would be the right behavior: the caller needs to
> > be authenticated to make sure it is allowed to use the tool, then it
> > should be authenticated on the target to make sure the operation is
> > allowed.
> > ...But this is much more complex.
> >
> > If this is fine for you, I would prefer to disable this feature when the
> > utility is setuid and not executed by root.
> >
> 
> I'm affraid this patch does not do what you think it does. The --root
> option does not apply to login, but only to the various administrative
> tools that comes with it (gpasswd, groupadd, groupdel, groupmod,
> grpconv, grpunconv, passwd, pwconv, pwunconv, useradd, userdel).

I understand this correctly.

Lets take the passwd use case.
passwd usually authenticates the caller (when UID==0, this authentication
is usually skipped), then asks for the new password, then update the
password databases.
passwd is suid and can be used by non root users to change the caller's
password. What should be the behavior of passwd is such case?
With the current patch, an user with UID 1000 will be allowed to change the
password of the user from the target chroot with the same UID 1000. 

In the patched tools you indicated, gpasswd is also suid.
And all the others can be suid when configured with
--enable-account-tools-setuid

My proposal is to only support --root for root. For non suid utils,
regular users will be denied chroot anyway, hence: "disable this feature
when the utility is setuid and not executed by root."

In your use case (for packaging), I assume the tools are always called by
root. Then this restriction should not affect you.

> It allows OE to manipulate passwd and group files that are located in
> a sysroot by chrooting into it, because all these programs have their
> path to /etc/passwd and friends hardcoded.

The advantage is not only that the destination user/group files are
changed, but also that they are changed considering the configuration of
the target system (e.g. PAM, /etc/login.defs, ...)

Best Regards,
-- 
Nekral