coreutils
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]