linux-kernel - Re: util-linux: orphan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Dec 2006 12:46:56 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Alessandro Suardi <alessandro.suardi@...il.com>
cc:	Theodore Tso <tytso@....edu>, "H. Peter Anvin" <hpa@...or.com>,
	Arnd Bergmann <arnd@...db.de>, Karel Zak <kzak@...hat.com>,
	linux-kernel@...r.kernel.org, Henne Vogelsang <hvogel@...e.de>,
	Olaf Hering <olh@...e.de>
Subject: Re: util-linux: orphan


On Dec 27 2006 12:24, Alessandro Suardi wrote:
> On 12/27/06, Theodore Tso <tytso@....edu> wrote:
>> On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote:

>>>> I saw that the current Fedora already dynamically links
>>>> /bin/mount against /usr/lib/libblkid.so. This obviously does not
>>>> work if /usr is a separate partition that needs to be mounted
>>>> /with bin/mount. I also had problems with selinux claiming I had
>>>> no right to access libblkid, which meant that the root fs could
>>>> not be remounted r/w.
>>>> 
>>>> I'd suggest that you make sure that mount always gets statically
>>>> linked against libblkid to avoid these problems.
>>> 
>>> That's a pretty silly statement.  The real issue is that any
>>> library needed by binaries in /bin or /sbin should live in /lib,
>>> not /usr/lib.
>> 
>> From a Debian unstable system:
>> 
>> think:~# ldd /bin/mount
>> libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000)
>
> FC6-current for i386 has it right:
>
> [root@...dman ~]# ldd /bin/mount
> libblkid.so.1 => /lib/libblkid.so.1 (0x4b607000)

And so does openSUSE 10.2:

ichi$ ldd /bin/mount
        libblkid.so.1 => /lib/libblkid.so.1 (0xa7f4f000)

Interestingly enough, SUSE Linux 10.1 i586/x86_64 had it statically
ccg$ ldd /bin/mount
        libc.so.6 => /lib64/libc.so.6 (0x00002b489072e000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
        (that's all folks)

Now what puzzles is that FC6's mapping address is quite 'off' - the
host "think" has it near PAGE_OFFSET (0xc0000000), as does "ichi"
(PAGE_OFFSET=0xb0000000), so what's with "sandman"?

	-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/