On Mon, May 18, 2015 at 04:30:33PM -0600, Todd C. Miller wrote:
Currently, chroot -u doesn't use the settings in /etc/login.conf.
This adds a -c option to apply the via setusercontext(). We can't
use LOGIN_SETALL since the uid change has to happen after chroot(2)
and the groups may be
On Mon, May 18, 2015 6:30 pm, Todd C. Miller wrote:
Currently, chroot -u doesn't use the settings in /etc/login.conf.
Nice. I was missing this option.
Open questions:
1) Should this just be default behavior with -u? Are there cases
when you would *not* want to set the priority and
The consensus seems to be that chroot -u should apply the settings
in /etc/login.conf by default. Since this is a non-standard flag
we can do what we like with it. I should have used setusercontext()
when I added -u to chroot in the first place.
We can add a -c class option in the future if
On Tue, 19 May 2015 09:56:53 -0600, Theo de Raadt wrote:
I think the consensus was easy to form. People using -u right now
collect root's giant limits, which is not sensible.
Actually, they retain the invoking user's limits. But either way,
it is surprising.
- todd
The consensus seems to be that chroot -u should apply the settings
in /etc/login.conf by default. Since this is a non-standard flag
we can do what we like with it. I should have used setusercontext()
when I added -u to chroot in the first place.
We can add a -c class option in the future
Currently, chroot -u doesn't use the settings in /etc/login.conf.
This adds a -c option to apply the via setusercontext(). We can't
use LOGIN_SETALL since the uid change has to happen after chroot(2)
and the groups may be specified via the -g option.
Open questions:
1) Should this just be
On Mon, May 18, 2015 at 04:30:33PM -0600, Todd C. Miller wrote:
Currently, chroot -u doesn't use the settings in /etc/login.conf.
This adds a -c option to apply the via setusercontext(). We can't
use LOGIN_SETALL since the uid change has to happen after chroot(2)
and the groups may be
