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