[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: chroot's userspec option
From: |
Pádraig Brady |
Subject: |
Re: chroot's userspec option |
Date: |
Thu, 27 Feb 2014 16:45:06 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
On 02/27/2014 03:48 PM, Ken Werner wrote:
> Hi,
>
> I noticed when using chroot's --userspec option the Gnulib's parse_user_spec
> function gets called that leads the glibc to dlopen libnss_compat.so.2
> (probably getpwnam() that triggers the libc's NSS mechanism). Since
> parse_user_spec is called after the chroot system call the new root directory
> will be searched. I guess this means that the chroot utility attempts to
> parse the user spec in the "guest" environment. Is this behavior intended? In
> my case the chroot environment contains a libnss_compat.so.2 that's not
> compatible and the chroot utility fails with:
>
> /usr/bin/chroot: relocation error: /lib/libnss_compat.so.2: symbol
> _nss_files_parse_pwent, version GLIBC_2.0 not defined in file libc.so.6 with
> link time reference
>
> As soon as I LD_PRELOAD libnss_compat.so.2 the "host" environment is used to
> parse the user spec. If this is the intended behavior it would be better if
> chroot calls the parse_user_spec prior issuing the chroot syscall. Any
> thoughts? :)
This issue was noted previously with an explicit workaround:
http://lists.gnu.org/archive/html/coreutils/2011-07/msg00057.html
Then again with an implicit workaround:
http://lists.gnu.org/archive/html/coreutils/2012-05/msg00018.html
I had mentioned an amendment to that but there was no response.
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;
thanks,
Pádraig.