[pacman-dev] dangerous symlink handling with --root option

[Mister Dobalina]

--- Xavier <shiningxc at gmail.com> wrote:

> On Mon, Aug 20, 2007 at 10:38:26PM -0400, Mister
> Dobalina wrote:
> > Hi again,
> > 
> > (and sorry again for any split lines)
> > 
> > Okay, so I was fooling around with the --root
> option
> > again, and after I realized from one of Xavier's
> posts
> > that pre/post install scriptlets won't be run at
> all
> > until /bin/sh (from bash) is installed, I figured
> I
> > should install the packages twice. This led to two
> > issues. I have a bash script (attached) that
> basically
> > does:
> >
> 
> I'm missing some basic *nix knowledge here :)
> When I saw this problem, I added /bin/sh and
> /bin/bash
> to my empty chroot, but it still didn't work.

Just bash in an empty chroot won't run because of
missing shared libraries -- an ldd of /bin/bash shows
it needs some libraries from readline, ncurses, and
glibc.
 
> Now, I just made an installation of filesystem and
> all its dependencies,
> and it seemed to work.
> The filesystem scriptlet complained though because
> grep was missing, but at
> least it was run.
> 
> 
> > pkglist=( ... bunch o' base packages ... )
> > mkdir /tmp/pacman.test
> > pacman -U --root /tmp/pacman.test ${pkglist[*]}
> > pacman -U --root /tmp/pacman.test ${pkglist[*]}
> > 
> > The second install of coreutils causes:
> > 
> > error: cannot remove file
> > '/tmp/pacman.test/usr/bin/sleep': Read-only file
> > system
> > error: failed to commit transaction (transaction
> > aborted)
> > error: failed to release transaction (could not
> commit
> > transaction)
> > 
> > First Issue: CPU usage then goes to 100%, so I
> assume
> > that pacman has gone into an infinite loop
> somewhere. 
> > 
> 
> I think this is the same issue as described there
> (in the quoted mails) :
>
http://www.archlinux.org/pipermail/pacman-dev/2007-August/009084.html
> 
> ie, when a -U operation failed, pacman always looped
> when trying to
> unregister the databases.
> My fix has just recently been pushed to git.

Ok great, glad you already knew about it.
 
> > Second Issue: the real concern is the "Read-only
> file
> > system" error, since /tmp is on a tmpfs and is
> > definitely not read-only. My / partition is
> read-only
> > though, and
> > 
> > # ls -l /tmp/pacman.test/usr/bin/sleep
> > 
> > lrwxrwxrwx 1 root root 10 2007-08-16 16:13
> > /tmp/pacman.test/usr/bin/sleep -> /bin/sleep
> > 
> > So pacman was following the absolute symlink *out*
> of
> > the --root and trying to remove /bin/sleep from my
> > main arch install ??
> >
> 
> Hmm, the question I would rather ask is wtf is that
> symlink in the first
> place ?
> sleep isn't a symlink here, it's a regular file.

/usr/bin/sleep should be a symlink to /bin/sleep on
your system. This is actually due to a bug report I
filed when I first started using archlinux a few years
ago. sleep was originally being installed in /usr/bin,
but this made it inaccessible during parts of
rc.sysinit/rc.shutdown for people who have /usr on a
separate partition. I always add a

sync; sleep 5

at the end of rc.shutdown, because my hard drive has a
large cache, and archlinux runs so quickly that it was
powering down my computer before the hard drive cache
was finished being written out to disk, causing an
fsck run on every boot. Anyways, Judd agreed that
sleep should go into /bin, but put a symlink in
/usr/bin for anybody that wasn't expecting sleep to
move.

> But even then, all other symlinks I've in the --root
> are correct, they don't
> point to somewhere outside it.

I guess it depends on whether the package maintainer
made it a relative or absolute symlink?
 
> $ ls -l foo/bin/sh
> lrwxrwxrwx 1 root root 4 mai 15 21:14 foo/bin/sh ->
> bash*
> $ ls -l foo/bin/sleep
> -rwxr-xr-x 1 root root 14380 aoû 16 22:13
> foo/bin/sleep*

foo/bin/sh -> bash is a relative symlink, points to
the same directory that the link itself is in. And
foo/bin/sleep is indeed the actually binary as it is
supposed to be installed. But you should really be
trying

# ls -l foo/usr/bin/sleep 

to see where it points.

cheers,
Jeremy



      Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca