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

[Roger Leigh]

Christian Hammers <ch at debian.org> writes:

> 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().

getcwd always returns the true absolute path.  The "fake" path is also
available from the shell as $PWD, but this is not what is going on in
this case, after some checking.

> My /home/ has been a symlink to /mnt/local/home for month and until now I
> started firefox in a chroot (amd64 vs i386 and flash plugin...) every day!
> Only since the last update yesterday dchroot tries to cd to "pwd -P" instead
> of "pwd". Why is this so?
>
> Is dchroot *now* a symlink to schroot and has been build from a different
> source in the months before?

Yes.  dchroot since last week (0.99.0-1) is now built from the schroot
source.  It's not a symlink, but under the hood it is schroot (a
static library at the moment) with a small shim to make it behave like
dchroot.  In this sense, it's basically a brand-new implementation,
and things like this are compatibility bugs in a sense.

I found the cause of the bug.  With the old dchroot:

$ pwd
/tmp/dchroot-0.13
$ dchroot -c sid pwd
(sid) pwd
/home/rleigh

So even though I'm in /tmp/dchroot-0.13, the command was executed in
my home directory.

With the new dchroot:

$ pwd
/tmp/dchroot-0.13
$ dchroot -c sid pwd
I: [sid chroot] Running command: ¡Èpwd¡É
/tmp/dchroot-0.13

In this case it uses the same directory inside the chroot.

> If so, what system call did the old dchroot use
> to get the path as it was apparently not getcwd(3).

The old dchroot executes the command in the chroot indirectly via
su(1).  This runs a login shell placing you in your home directory, so
you get the behaviour of su, and it probably doesn't do this sanity
check (it's not aware of the dangers of chroots).  Additionally, you
have the above behaviour difference: it always ensures you are in
$HOME; it doesn't attempt to do otherwise unless you use the "-d"
option.

There are also less visible differences as well.  For example, schroot
does careful sanitisation of the environment in the same manner as
sudo, and this might also cause problems in some cases.

> Surely I could change my system to use bindmounts but it maybe annoys
> others, too :)

I have had a couple of mails in the last week about it.  It's hard to
know where to draw the line between usability and safety, and it took
some time to reach the decision to use the current behaviour.  The
main reason for it is safety--I would rather have an error than the
user have dataloss due to something unexpected happening.

On the other hand, backward compatibility is important.  Any comment
on this would be most welcome!


Regards,
Roger

-- 
Roger Leigh
                Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20060621/9d771b16/attachment.pgp