Linus Torvalds [off-list ref] writes:
Hmm.. That should work fine. You can already just run it that way by just
wrapping it in "chroot", but if you don't want that for some reason, how
about a patch like this?
Later exchanges between you and HPA appeared to me that we would
need a chroot environment which has "enough stuff" and that this
patch may not help him very much. Am I mistaken?
If not, then...
+ if (!strncmp(arg, "--chroot=", 9)) {
+ if (chroot(arg+9) < 0)
+ die("unable to chroot to '%s': %s", arg+9, strerror(errno));
+ if (chdir("/") < 0)
+ die("unable to chdir to new root");
+
+ user = user ? user : "nobody";
+ group = group ? group : "nobody";
+ continue;
+ }
+
+ if (!strncmp(arg, "--user=", 7)) {
+ user = arg+7;
+ continue;
+ }
I think resolving user and group to numeric before you do
chroot() might make the setting up of chrooted environment a
little simpler; no need for supporting getpwnam and getgrnam
there. On the other hand it may not matter -- you can always
give numeric uid/gid to begin with.
Junio C Hamano wrote:
Later exchanges between you and HPA appeared to me that we would
need a chroot environment which has "enough stuff" and that this
patch may not help him very much. Am I mistaken?
Well, building a chroot environment which supports execing is a bit of a
pain, but it's fully doable. mount --bind especially makes that quite
feasible. It's just more work.
I think resolving user and group to numeric before you do
chroot() might make the setting up of chrooted environment a
little simpler; no need for supporting getpwnam and getgrnam
there. On the other hand it may not matter -- you can always
give numeric uid/gid to begin with.
Yes, resolve the username first.
-hpa
On Fri, 16 Sep 2005, Junio C Hamano wrote:
Later exchanges between you and HPA appeared to me that we would
need a chroot environment which has "enough stuff" and that this
patch may not help him very much. Am I mistaken?
No, I think that's correct.
I think resolving user and group to numeric before you do
chroot() might make the setting up of chrooted environment a
little simpler; no need for supporting getpwnam and getgrnam
there.
Right you are. Much better.
On the other hand it may not matter -- you can always
give numeric uid/gid to begin with.
Well, the symbolic names are much nicer and more readable. So it would be
better to do the uid/gid translation early, and change the "chroot" thing
to be done after all that.
It gets a bit messy.. Easy enough to just save a "const char *new_root",
but then you have to split up the "set_user_group()" to be two functions,
around the actual chroot(), since the chroot needs to be done while we're
still root.
I think we can drop the patch for now. It doesn't buy much.
Linus
Linus Torvalds wrote:
Well, the symbolic names are much nicer and more readable. So it would be
better to do the uid/gid translation early, and change the "chroot" thing
to be done after all that.
It gets a bit messy.. Easy enough to just save a "const char *new_root",
but then you have to split up the "set_user_group()" to be two functions,
around the actual chroot(), since the chroot needs to be done while we're
still root.
Actually, initgroups() and setgroups(), and setgid() for that matter,
can be done before the chroot(). The only thing that needs to remain
until the end is setuid().
At one time I played around in tftp-hpa with trying to get Linux to keep
only CAP_SYS_CHROOT around, but I think I gave up on it. The way Linux
capabilities play with the rest of the permission system isn't very
useful :(
-hpa