bug#18062: [PATCH] chroot: always change to / if not changing credentials

[Bernhard Voelker]

On 07/20/2014 06:10 PM, Andreas Schwab wrote:
> Bernhard Voelker <address@hidden> writes:
>> And why should "chroot /" invoke chroot(2)
> 
> What else do you expect from a command called chroot???

Let's resume:
1) The change to skip chroot() for the root directory and
synonyms was made for consistency with systems where this
is already allowed for non-root users by the kernel.
I consider this a good choice.

2) The same if-clause also skips the determination of the new
uid/gid/supplementary groups because the result would be the same
during the second determination _after_ chroot("/").
Note the functionality for changing the uid/gid/suppl. groups
had already been there and had just been improved for numeric ids.
This therefore was an optimization to omit redundant processing,
thus a good choice, too.

3) The choice for moving the chdir("/") inside the same if-clause
was made because it's cool to use things like
  chroot --user=$NON_ROOT_USERNAME / env PATH="$PATH" cp -p c c2
without the need to chdir() to the previous directory inside the
chroot jail.  Admittedly, this might break the expectations of
some previously existing use cases - as we see in your OBS log.
;-(

Now, what to do?

a) leave it as it is?
This would most probably break several scripts and cause much
unexpected work for our users.

b) revert part 1), i.e. chroot() for "/" again?
This would re-introduce previous discrepancy in behavior
on different systems.

c) revert part 3), i.e. chdir("/") in any case?
This would require some work on our tests, because we couldn't
use commands like above as easy as this.

Please correct me if I overlooked something.

Jim?

Thanks & have a nice day,
Berny