* Re: --root option in upstream shadow [not found] <20111022115412.GM16703@nekral.nekral.homelinux.net> @ 2011-10-24 0:06 ` Julian Pidancet 2011-10-26 20:51 ` Nicolas François 0 siblings, 1 reply; 3+ messages in thread From: Julian Pidancet @ 2011-10-24 0:06 UTC (permalink / raw) To: openembedded-core, Scott Garman, Julian Pidancet, pkg-shadow-devel On Sat, Oct 22, 2011 at 12:54 PM, Nicolas François <nicolas.francois@centraliens.net> wrote: > Hello, > > I'm the upstream maintainer of the shadow utilities. > > I was informed of the OpenEmbedded's add_root_cmd_options patch and would > like to integrate it upstream. > > First of all, thanks a lot for implementing this feature. I was asked > multiple times for it or something similar, but never found time to work > on it. > > I did not review it completely yet, but would have a question. > 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. > > Best Regards, Hi Nicolas, 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). 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. This way, when OE builds a package which needs a special user to be present at run-time, it can create the user off-line at build-time instead of beeing required to create post-install scripts which does the same job but has to be executed at run-time. -- Julian ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: --root option in upstream shadow 2011-10-24 0:06 ` --root option in upstream shadow Julian Pidancet @ 2011-10-26 20:51 ` Nicolas François 2011-10-26 21:04 ` Mark Hatle 0 siblings, 1 reply; 3+ messages in thread From: Nicolas François @ 2011-10-26 20:51 UTC (permalink / raw) To: julian.pidancet; +Cc: pkg-shadow-devel, Scott Garman, openembedded-core Hi, On Mon, Oct 24, 2011 at 01:06:11AM +0100, julian.pidancet@gmail.com wrote: > On Sat, Oct 22, 2011 at 12:54 PM, Nicolas François > <nicolas.francois@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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: --root option in upstream shadow 2011-10-26 20:51 ` Nicolas François @ 2011-10-26 21:04 ` Mark Hatle 0 siblings, 0 replies; 3+ messages in thread From: Mark Hatle @ 2011-10-26 21:04 UTC (permalink / raw) To: julian.pidancet, openembedded-core, Scott Garman, pkg-shadow-devel On 10/26/11 3:51 PM, Nicolas François wrote: > Hi, > > On Mon, Oct 24, 2011 at 01:06:11AM +0100, julian.pidancet@gmail.com wrote: >> On Sat, Oct 22, 2011 at 12:54 PM, Nicolas François >> <nicolas.francois@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. The existing behavior we use in OpenEmbedded-core is emulate root user (we do this by call intercepting, and avoiding suid/sgid).. But under the hood, it all comes down to file permissions. If we have permission to modify the file we do -- otherwise it fails. This is equivalent to the root user. There are reasonable cases where a non-root user (with permission to modify the passwd/group file within a chroot) will want to do so.. This sounds like a security flaw, but it's not because the permissions are added to the chroot after the filesystem is finished being constructed. > 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." I agree, with setuid it doesn't make sense to allow --root functionality. Would it be reasonable to drop the setuid/gid if the user attempts --root functionality. Internally act as if the user is root and then simply allow the filesystem dictate success or failure? > In your use case (for packaging), I assume the tools are always called by > root. Then this restriction should not affect you. The tool THINKS it's called as root, but it's actually called as a user. (We use a utility called pseudo that intercepts calls and emulated root capabilities.) But some of our embedded requirements are unique to our build environments. So if the default action is only root can perform the --root command, we can easily remove the check -- or change it that it doesn't function if setuid for our purposes. (but with pseudo I don't think this will be an issue.) >> 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, ...) Absolutely! Thanks. Anything we can do to get this upstream will make it much easier for us in the long term. --Mark > Best Regards, ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-10-26 21:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20111022115412.GM16703@nekral.nekral.homelinux.net>
2011-10-24 0:06 ` --root option in upstream shadow Julian Pidancet
2011-10-26 20:51 ` Nicolas François
2011-10-26 21:04 ` Mark Hatle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox