|
From: | Ken Werner |
Subject: | Re: chroot's userspec option |
Date: | Sat, 01 Mar 2014 08:41:06 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
On 02/28/2014 12:00 PM, Bernhard Voelker wrote:
On 02/28/2014 11:34 AM, Ken Werner wrote:On 02/27/2014 05:45 PM, Pádraig Brady wrote:I'll look at a fix now to do: t_ids = parse_user_spec(); //outside chroot ids = parse_user_spec(); //inside chroot if (!ids) ids = t_ids;Thank you for providing those pointers! I have to admit that it's still> not clear to me whether the userspec option is supposed to lookup the > user/group using the A) the old or B) the new root. Hmm, this'd have another implication: if a username resolves differently out- versus inside, then it'd not very transparent for the caller which of the two will be taken. This could only be avoided by a new option like "--userspec-outside". I'm not sure if this has been discussed before, but as numerical IDs already work, I'm 80:20 against adding it.
Please don't get me wrong - I didn't state that I'm in favor of A). From the documentation it's just not clear what --userspec really does (or is supposed to do) when using names rather than IDs. As you wrote the UID/GID mapping of the old root doesn't necessarily have to match with what the new root specifies. So the cases might be rare where A) is really useful. Imho the same is true for B) as I can't think of a sane way to properly implement this. The current implementation requires the NSS modules of the new root to be compatible with the libc of the old root. I've been looking for a way to skip the lookup of names because I do not rely on it at all. For me the preferred behavior would be have chroot to just use the numeric IDs for the setuid/setgid calls. When I wrote the mail that started this thread I wasn't aware that this can be achieved by prefixing the IDs with '+'. It turns out that using numeric IDs for --userspec does work if know how to specify them. : )
Regards, Ken
[Prev in Thread] | Current Thread | [Next in Thread] |