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
