Bug#374713: [Buildd-tools-devel] Bug#374713: Aborts if cd fails but seems to use pwd -P

Christian Hammers ch at lathspell.de
Wed Jun 21 20:25:44 UTC 2006


Hello

On 2006-06-21 Christian Hammers wrote:
> Hello Roger
> 
> On 2006-06-21 Roger Leigh wrote:
> > Christian Hammers <ch at debian.org> writes:
> > 
> > > dchroot stopped working for me. I tried schroot but it complains about
> > > the same:
> > >
> > >   $ pwd   
> > >   /home/ch
> > >
> > >   $ pwd -P
> > >   /mnt/local/home/ch
> > >
> > >   $ dchroot pwd
> > >   E: Could not chdir to '/mnt/local/home/ch': No such file or directory
> > >   E: Session failure: Child exited abnormally with status '1'
>  
> 
> > The first thing is pwd.  I'm assuming here that /home/ch is a symlink
> > to /mnt/local/home/ch, or /home is a symlink to /mnt/local/home.  When
> > schroot runs, it can only rely on the path as obtained with getcwd(3).
> 
> Thanks for the long explanation but the rationale why it tries to be in the
> same path as before when running non-interactively is clear to me -
> what I wondered is why it seems to have *changed* the behaviour regarding
> the return of getcwd().

Ok, I've just debugged it a bit. dchroot has indeed completely changed the
source.

In the old version dchroot-0.13 it jumped to the home directory as specified 
in /etc/passwd *always*, regardless of the actual cwd of the calling user.
It did this by executing e.g. "/bin/su - ch -c foobar".

My suggestion would be to change the code to do something like:
  p = popen("/bin/sh -c 'pwd'", "r");
  target_dir = fgets(p);
  ... chroot() ...
  chdir(target_dir);

bye,

-christian-




More information about the Buildd-tools-devel mailing list