On Monday 15 November 2010 21.55.36 Miklos Szeredi wrote:
> On Mon, 15 Nov 2010, Karl-Johan Karlsson wrote:
> > [pid 1129] readlink("/proc/self/fd/0", "(unreachable)/dev/console"...,
> > 4095) = 25
> > [pid 1129] write(7, "OPTION ttyname=(unreachable)/dev/console", 40
> > <unfinished ...>
> > [pid 1132] <... read resumed> "OPTION
> > ttyname=(unreachable)/dev/console", 1002) = 40
> > [pid 1132] open("(unreachable)/dev/console", O_RDONLY) = -1 ENOENT (No
> > such file or directory)
>
> Blindly trusting readlink on a /proc/*/fd/ file to yield a valid
> absolute path has always been wrong.
>
> That readlink comes from a ttyname(3) call, I suppose. A fix to
> ttyname() has already been added to glibc git:
>
> 0e516e0e Verify in ttyname() that the symlink is valid.
Yes, when I apply that patch it works. Thanks!
> > I suppose the real bug is that /dev/console is considered unreachable,
> > when (according to strace) no process has done chroot() and the initrd
> > has a
> >
> > functioning /dev/console:
> > crw-r--r-- 1 root root 5, 1 1 jul 2007 dev/console
>
> What filesystem is this on? The original console fd comes from
> rootfs, and initrd probably already did a pivot_root().
No, this is still the initrd. This work is done to set up the encrypted real
root device, so there is nothing to pivot_root() to yet. Also, as per the
bisection, this worked until your commit above, so obviously pinentry-curses
has been able to get the passphrase from /dev/console before.
Here's the initrd's init script up to this point:
#!/bin/bash
export PATH=/bin:/usr/bin:/sbin
mount -t proc none /proc
CMDLINE=`cat /proc/cmdline`
false
while [ $? -ne 0 ]
do
umount /cryptroot
cryptsetup remove cryptroot
gpg --quiet -d /boot/root-key.gpg | cryptsetup -h plain -c aes-xts-plain -s
512 create cryptroot /dev/sda3
mount -t ext4 -o noatime,barrier=1 /dev/mapper/cryptroot /cryptroot
done
--
Karl-Johan Karlsson
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
