It really seems that util-linux project is in a bad condition:
* the latest *major* stable release: 05-Mar-2004 (util-linux-2.12a)
* the latest *minor* stable release: 23-Sep-2005 (util-linux-2.12r)
* the latest unstable release: 05-Mar-2006 (util-linux-2.13-pre7)
* missing source code repository
* missing web page
* maintainer (Adrian Bunk) completely ignores mails about this package
* source code doesn't follow linux kernel, because there isn't any
development
* contributors are sending their patches to distributions rather than
to upstream
* Red Hat (FC6) has 75 patches for this package (!)
* Novell has (OpenSuse 10.2) 53 patches for this package (!)
I'm Red Hat util-linux maintainer (for 2 years) and I'd like to
change this bad situation. Yes.. I'd like to help. I've already
talked with Peter Anvin about git repository for this project at
kernel.org. Also I have feedback from Novell that they agree that the
current situation is bad and they want to contribute future
development.
My plan:
* create git repo (stable and unstable branches) at kernel.org
* create some web page with basic pkg description, TODO, changelogs
* open util-linux development for more people
* merge importantpatches from distros to the upstream code and
release 2.13 as stable
* prepare plans for future development:
- don't maintain duplicate code and use libblkid/libvolumeid only
- completely remove NFS code (we have nfs-utils and
/sbin/mount.nfs)
- write modular libmount and use it in other projects (am-utils,
autofs, mount.cif, mount.nfs, ...)
- ???
I've originally thought about util-linux upstream fork, but as
usually an fork is bad step. So.. I'd like to start some discussion
before this step. Maybe Adrian will be realistic and he will leave
the project and invest all his time to kernel only.
Karel
--
Karel Zak <[email protected]>
Karel Zak wrote:
>
> I've originally thought about util-linux upstream fork, but as
> usually an fork is bad step. So.. I'd like to start some discussion
> before this step. Maybe Adrian will be realistic and he will leave
> the project and invest all his time to kernel only.
>
Actually, forking is not really that bad of an idea. When I took over
tftp, for example, I just did it and called it tftp-hpa. It didn't take
very long before I got a message from the netkit maintainer asking if I
was planning to continue, and if so if he could drop tftp from netkit.
A similar thing happened when Jeremy (and now Ian) took over autofs from me.
Forking gets your new maintainership proven *before* you end up taking
over. On the other hand, magicfilter effectively died when I handed it
over to someone who didn't do a good job with it.
-hpa
Karel Zak wrote:
> It really seems that util-linux project is in a bad condition:
Here here. I mentioned this a few months back to no avail:
http://lkml.org/lkml/2006/6/27/310
Adrian can you please hand over maintainership ASAP.
thanks,
P?draig.
p.s. I included util-linux as a bad example
in an OSS openness metric I was thinking about:
http://www.pixelbeat.org/docs/oss_project_quality.html
Hello,
after few weeks I'm pleased to announce a new "util-linux-ng" project. This
project is a fork of the original util-linux (2.13-pre7).
The goal of the project is to move util-linux code back to useful state, sync
with actual distributions and kernel and make development more transparent end
open.
The short term goals (for 2.13 release):
- remove all NFS code from util-linux-ng
(/sbin/mount.nfs from nfs-utils is replacement)
- remove FS/device detection code
(libblkid from e2fsprogs or libvolumeid is replacement)
- move as much as possible patches from distributions to upstream
Mailing list:
http://vger.kernel.org/vger-lists.html#util-linux-ng
FTP:
ftp://ftp.kernel.org/pub/scm/utils/util-linux-ng/
GIT:
git clone git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git util-linux-ng
[Note, GIT repo contains previous 47 versions of util-linux.]
The mailing list or my private e-mail are open for your patches, ideas and
suggestion. The mailing list is also place where you can help us review
patches.
Thanks mostly to Ian Kent, P.H. Anvin. Well, and thanks to Adrian
Bunk for his previous work on this package.
Karel
On Thu, Nov 09, 2006 at 11:41:57PM +0100, Karel Zak wrote:
>
> It really seems that util-linux project is in a bad condition:
>
> * the latest *major* stable release: 05-Mar-2004 (util-linux-2.12a)
> * the latest *minor* stable release: 23-Sep-2005 (util-linux-2.12r)
> * the latest unstable release: 05-Mar-2006 (util-linux-2.13-pre7)
> * missing source code repository
> * missing web page
> * maintainer (Adrian Bunk) completely ignores mails about this package
> * source code doesn't follow linux kernel, because there isn't any
> development
> * contributors are sending their patches to distributions rather than
> to upstream
> * Red Hat (FC6) has 75 patches for this package (!)
> * Novell has (OpenSuse 10.2) 53 patches for this package (!)
>
>
> I'm Red Hat util-linux maintainer (for 2 years) and I'd like to
> change this bad situation. Yes.. I'd like to help. I've already
> talked with Peter Anvin about git repository for this project at
> kernel.org. Also I have feedback from Novell that they agree that the
> current situation is bad and they want to contribute future
> development.
>
> I've originally thought about util-linux upstream fork, but as
> usually an fork is bad step. So.. I'd like to start some discussion
> before this step. Maybe Adrian will be realistic and he will leave
> the project and invest all his time to kernel only.
--
Karel Zak <[email protected]>
> after few weeks I'm pleased to announce a new "util-linux-ng" project. This
> project is a fork of the original util-linux (2.13-pre7).
>
> The goal of the project is to move util-linux code back to useful state, sync
> with actual distributions and kernel and make development more transparent end
> open.
If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
the maintainer, ask if you can take over, including the name.
This smells a lot like the RPM case [ http://lwn.net/Articles/196523/ ]
however, it does not look like anyone is going to call it rpm-ng just
because the original name is owned by the last maintainer.
Regards,
-`J'
--
On Monday 18 December 2006 10:33, Jan Engelhardt wrote:
> > after few weeks I'm pleased to announce a new "util-linux-ng" project.
> > This project is a fork of the original util-linux (2.13-pre7).
> >
> > The goal of the project is to move util-linux code back to useful state,
> > sync with actual distributions and kernel and make development more
> > transparent end open.
>
> If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
> the maintainer, ask if you can take over, including the name.
> This smells a lot like the RPM case [ http://lwn.net/Articles/196523/ ]
> however, it does not look like anyone is going to call it rpm-ng just
> because the original name is owned by the last maintainer.
rpm.org case is even worse. Original maintainer still develops rpm - at this
moment version 4.4.7 at http://wraptastic.org/ (while rpm.org starts from
older 4.4.2 codebase), there is active mailing list, so we have two running
projects with the same name which is bad thing and will cause confusion.
I hope that there will be one util-linux and one rpm project.
> Regards,
> -`J'
--
Arkadiusz Mi?kiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
Jan Engelhardt <[email protected]> writes:
>> after few weeks I'm pleased to announce a new "util-linux-ng" project. This
>> project is a fork of the original util-linux (2.13-pre7).
>>
>> The goal of the project is to move util-linux code back to useful state, sync
>> with actual distributions and kernel and make development more transparent end
>> open.
>
> If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
> the maintainer, ask if you can take over, including the name.
Well, there hasn't been any response since about one month. I think the decision
to fork in this situation is reasonable. We all hope that it will be just a
temporary fork.
Matthias
Karel Zak writes:
> I've originally thought about util-linux upstream fork,
> but as usually an fork is bad step. So.. I'd like to start
> some discussion before this step.
...
> after few weeks I'm pleased to announce a new "util-linux-ng"
> project. This project is a fork of the original util-linux (2.13-pre7).
Aw damn, I missed it again. LKML gets about 300 posts/day. The last
time util-linux was offered, I missed out. Bummer.
Well, how about giving me a chunk of it? I'd like /bin/kill please.
I already ship a nicer one in procps anyway, so you can just delete
the files and call that done. (just today I was working on a Fedora
system and /bin/kill annoyed me)
VERY STRONG SUGGESTION: build a full test suite before you mess with
the source. This isn't some cute toy like xeyes or a silly game.
This is util-linux, which MUST work.
>> I've originally thought about util-linux upstream fork,
>> but as usually an fork is bad step. So.. I'd like to start
>> some discussion before this step.
> ...
>> after few weeks I'm pleased to announce a new "util-linux-ng"
>> project. This project is a fork of the original util-linux (2.13-pre7).
>
> Well, how about giving me a chunk of it? I'd like /bin/kill please.
> I already ship a nicer one in procps anyway, so you can just delete
> the files and call that done. (just today I was working on a Fedora
> system and /bin/kill annoyed me)
How can you ship a "nicer" kill, given that its sole purpose is to accept
kill { -l | -t | {-s SIGNUM | -SIGNAME } somepid [morepids] }
?
What about merging util-linux and procps?
-`J'
--
On 12/20/06, Jan Engelhardt <[email protected]> wrote:
>
> >> I've originally thought about util-linux upstream fork,
> >> but as usually an fork is bad step. So.. I'd like to start
> >> some discussion before this step.
> > ...
> >> after few weeks I'm pleased to announce a new "util-linux-ng"
> >> project. This project is a fork of the original util-linux (2.13-pre7).
> >
> > Well, how about giving me a chunk of it? I'd like /bin/kill please.
> > I already ship a nicer one in procps anyway, so you can just delete
> > the files and call that done. (just today I was working on a Fedora
> > system and /bin/kill annoyed me)
>
> How can you ship a "nicer" kill, given that its sole purpose is to accept
>
> kill { -l | -t | {-s SIGNUM | -SIGNAME } somepid [morepids] }
>
> ?
I checked compatibility with Solaris, Tru64, probably a few BSDs,
and man pages of many others.
Fedora Core 5 doesn't seem to like this command:
/bin/kill -l 17 19
(which reminds me, I need to add sigqueue support and
maybe tgkill support)
> What about merging util-linux and procps?
How? Which way?
As I mentioned before, I was twice disappointed in missing
announcements of util-linux maintainership being up for grabs.
I certainly have a track record for keeping things stable.
Prior to me, procps has a history of being abandoned and
broken. Procps is a fork of the long-dead kmem-ps project.
Procps was then passed to someone who added color and
then disappeared. The prior maintainer picked up the old
code again, no doubt under influence of his employer Red Hat.
I rewrote much of it then, but had trouble getting in all of
my changes. Debian started using my code, which slowly
turned into a fork. Maintainership was passed to somebody
else, without even telling me. That person and his immediate
successor added numerous serious bugs. Inexperience with
the code and the lack of a test suite soon led to that group
being bogged down in problems. One by one, the various
Linux distributions switched over to my version of the code.
So as you may imagine, I'd be rather nervous about letting
procps get into that situation again. Bugs are yucky. Having
multiple committers and no testing is a sure path to ruin.
>> What about merging util-linux and procps?
>
> How? Which way?
In that all the following tools (and possibly files) which are
returned by `rpm ql procps` replace the util-linux counterparts, if
any. Note that rpm -ql might return less programs than actually
present in procps, since distributors need to choose which program to
pick from what {util-linux or procps}.
21:07 ichi:~ > rpm -ql procps
/bin/ps
/etc/init.d/boot.sysctl
/etc/sysctl.conf
/etc/xinetd.d/systat
/sbin/sysctl
/usr/bin/free
/usr/bin/pgrep
/usr/bin/pkill
/usr/bin/pmap
/usr/bin/pwdx
/usr/bin/skill
/usr/bin/slabtop
/usr/bin/snice
/usr/bin/tload
/usr/bin/top
/usr/bin/vmstat
/usr/bin/w
/usr/bin/watch
+ the stuff in /usr/share/doc and /usr/share/man
with the idea that you retain maintership over these. So my proposal/idea was
just one of how to package it.
> being bogged down in problems. One by one, the various
> Linux distributions switched over to my version of the code.
>
> So as you may imagine, I'd be rather nervous about letting
> procps get into that situation again. Bugs are yucky. Having
> multiple committers and no testing is a sure path to ruin.
-`J'
--
On Monday 18 December 2006 08:17, Karel Zak wrote:
> ????????- remove FS/device detection code
> ? ? ? ? ? (libblkid from e2fsprogs or libvolumeid is replacement)
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.
Arnd <><
Arnd Bergmann wrote:
> On Monday 18 December 2006 08:17, Karel Zak wrote:
>> - remove FS/device detection code
>> (libblkid from e2fsprogs or libvolumeid is replacement)
>
> 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.
-hpa
On Wednesday 27 December 2006 04:08, H. Peter Anvin wrote:
>
> > 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.
Right, this is obviously true in general. I don't understand enough
about selinux (who does?) to be sure what went wrong there on top
of this, but my impression was that I could have solved the problem
if I had been able to remount the root partition, or mount the selinux
file system, which was made impossible by the fact that I had no
permission to access one of the libraries for the mount binary.
The location of the library file was not the problem I had, as that
system doesn't have a separate /usr partition.
Arnd <><
Once upon a time, Arnd Bergmann <[email protected]> said:
>I saw that the current Fedora already dynamically links /bin/mount
>against /usr/lib/libblkid.so.
What do you mean by "current" Fedora? I think the first Fedora version
that linked /bin/mount against libblkid.so was FC4, and FC4, FC5, FC6,
and rawhide all have libblkid.so in /lib.
--
Chris Adams <[email protected]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
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
linux-gate.so.1 => (0xffffe000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7f20000)
libc.so.6 => /lib/libc.so.6 (0xb7ddf000)
libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xb7dcd000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb7db8000)
libsepol.so.1 => /lib/libsepol.so.1 (0xb7d77000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7d61000)
/lib/ld-linux.so.2 (0xb7f3f000)
libdl.so.2 => /lib/libdl.so.2 (0xb7d5d000)
... and in fact the e2fsprogs's configure program normally installs
the critical libraries used by mount, fsck, e2fsck, including the
blkid and uuid libraries, in /lib, not /usr/lib. If blkid is being
installed in /usr/lib in Fedora, someone must have gone out of their
way to override e2fsprogs' defaults, which are designed to do the
right things by default. (Basically, because I generally don't trust
the choices made by distributions' packaging engineers, having been
burned more than once. :-)
- Ted
On 12/27/06, Theodore Tso <[email protected]> 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
> linux-gate.so.1 => (0xffffe000)
> libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000)
> libuuid.so.1 => /lib/libuuid.so.1 (0xb7f20000)
> libc.so.6 => /lib/libc.so.6 (0xb7ddf000)
> libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xb7dcd000)
> libselinux.so.1 => /lib/libselinux.so.1 (0xb7db8000)
> libsepol.so.1 => /lib/libsepol.so.1 (0xb7d77000)
> libpthread.so.0 => /lib/libpthread.so.0 (0xb7d61000)
> /lib/ld-linux.so.2 (0xb7f3f000)
> libdl.so.2 => /lib/libdl.so.2 (0xb7d5d000)
>
> ... and in fact the e2fsprogs's configure program normally installs
> the critical libraries used by mount, fsck, e2fsck, including the
> blkid and uuid libraries, in /lib, not /usr/lib. If blkid is being
> installed in /usr/lib in Fedora, someone must have gone out of their
> way to override e2fsprogs' defaults, which are designed to do the
> right things by default. (Basically, because I generally don't trust
> the choices made by distributions' packaging engineers, having been
> burned more than once. :-)
>
> - Ted
FC6-current for i386 has it right:
[root@sandman ~]# rpm -qf /bin/mount
util-linux-2.13-0.45.3.fc6
[root@sandman ~]# ldd /bin/mount
linux-gate.so.1 => (0xb7f63000)
libblkid.so.1 => /lib/libblkid.so.1 (0x4b607000)
libuuid.so.1 => /lib/libuuid.so.1 (0x4b601000)
libselinux.so.1 => /lib/libselinux.so.1 (0x49ce5000)
libc.so.6 => /lib/libc.so.6 (0x00aec000)
libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x49cfe000)
libdl.so.2 => /lib/libdl.so.2 (0x00c54000)
libsepol.so.1 => /lib/libsepol.so.1 (0x4a603000)
/lib/ld-linux.so.2 (0x0011d000)
--alessandro
"...when I get it, I _get_ it"
(Lara Eidemiller)
On Dec 27 2006 12:24, Alessandro Suardi wrote:
> On 12/27/06, Theodore Tso <[email protected]> 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@sandman ~]# 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'
--
Fedora rawhide (i686):
$ rpm -qf /bin/mount
util-linux-2.13-0.48.fc7
$ ldd /bin/mount
linux-gate.so.1 => (0x00f9b000)
libblkid.so.1 => /lib/libblkid.so.1 (0x45dbc000)
libuuid.so.1 => /lib/libuuid.so.1 (0x45db6000)
libselinux.so.1 => /lib/libselinux.so.1 (0x43c5c000)
libc.so.6 => /lib/libc.so.6 (0x430d9000)
libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x4329c000)
libdl.so.2 => /lib/libdl.so.2 (0x43255000)
libsepol.so.1 => /lib/libsepol.so.1 (0x43c8b000)
/lib/ld-linux.so.2 (0x5e3f7000)
Aurora Corona (SPARC64):
$ rpm -qf /bin/mount
util-linux-2.13-0.44.sparc.al3
$ ldd /bin/mount
libblkid.so.1 => /lib/libblkid.so.1 (0xf7fbc000)
libuuid.so.1 => /lib/libuuid.so.1 (0xf7fa8000)
libselinux.so.1 => /lib/libselinux.so.1 (0xf7f80000)
libc.so.6 => /lib/libc.so.6 (0xf7e10000)
libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xf7dfc000)
libdl.so.2 => /lib/libdl.so.2 (0xf7de4000)
libsepol.so.1 => /lib/libsepol.so.1 (0xf7d88000)
/lib/ld-linux.so.2 (0x70000000)
CentOS 4.4 (x86_64):
$ rpm -qf /bin/mount
util-linux-2.12a-16.EL4.20
$ ldd /bin/mount
libc.so.6 => /lib64/tls/libc.so.6 (0x00000031d6c00000)
/lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
All look fine to me.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote:
> 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.
Well, there's a real treat here - lots of shared libraries mean
mount is rendered unusable when they are not available for some reason.
And there could be lots of reasons for this. We've seen selinux mislabeling
with a fedoro-ish box in the lab, there is the possibility of unintentional
ABI breaks and so on and so on.
Then again using shared libraries has big advtantags over duplicating all
the code, so I wouldn't want to say I'm totally against it. As mount
only needs the various libraries for it's non-core features what about
dlopen()ing those libraries? That way a messed up system at least has the
bare mount functionality available.
On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> On Monday 18 December 2006 08:17, Karel Zak wrote:
> > - remove FS/device detection code
> > (libblkid from e2fsprogs or libvolumeid is replacement)
>
> I saw that the current Fedora already dynamically links /bin/mount
> against /usr/lib/libblkid.so.
Sorry, but it's nonsense.
$ grep -r %{_root_libdir}/libblkid.so *
devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-1/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-2/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-3/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-4/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-5/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-5/e2fsprogs.spec~:%{_root_libdir}/libblkid.so.*
FC-6/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
RHEL-4/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
RHEL-5/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
(where %{_root_libdir} = /lib)
> This obviously does not work if /usr is a separate partition that
> needs to be mounted with /bin/mount.
Yes, I have /usr on a separate partition for many years :-)
> I'd suggest that you make sure that mount always gets statically linked
> against libblkid to avoid these problems.
It's dynamically linked in many distributions without a problem.
Karel
--
Karel Zak <[email protected]>
On Wednesday 27 December 2006 19:15, Karel Zak wrote:
>
> On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> > On Monday 18 December 2006 08:17, Karel Zak wrote:
> > > - remove FS/device detection code
> > > (libblkid from e2fsprogs or libvolumeid is replacement)
> >
> > I saw that the current Fedora already dynamically links /bin/mount
> > against /usr/lib/libblkid.so.
>
> Sorry, but it's nonsense.
>
> $ grep -r %{_root_libdir}/libblkid.so *
>
> devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
Right, please accept my apologies for spreading confusion about this.
I currently don't have access to the machine that broke, so I could
not check the exact problem, and must have misremembered the bug.
> > This obviously does not work if /usr is a separate partition that
> > needs to be mounted with /bin/mount.
>
> Yes, I have /usr on a separate partition for many years :-)
>
> > I'd suggest that you make sure that mount always gets statically linked
> > against libblkid to avoid these problems.
>
> It's dynamically linked in many distributions without a problem.
The problem that I saw was because of selinux going wild. Statically linking
would have avoided the problem for me, but I guess this is just one
more reason for me to disable selinux and be done with it.
Arnd <><
On Wed, Dec 27, 2006 at 07:39:47PM +0100, Arnd Bergmann wrote:
> On Wednesday 27 December 2006 19:15, Karel Zak wrote:
> >
> > On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> > > On Monday 18 December 2006 08:17, Karel Zak wrote:
> > > > - remove FS/device detection code
> > > > (libblkid from e2fsprogs or libvolumeid is replacement)
> > >
> > > I saw that the current Fedora already dynamically links /bin/mount
> > > against /usr/lib/libblkid.so.
> >
> > Sorry, but it's nonsense.
> >
> > $ grep -r %{_root_libdir}/libblkid.so *
> >
> > devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
>
> Right, please accept my apologies for spreading confusion about this.
No problem ;-)
> I currently don't have access to the machine that broke, so I could
> not check the exact problem, and must have misremembered the bug.
>
> > > This obviously does not work if /usr is a separate partition that
> > > needs to be mounted with /bin/mount.
> >
> > Yes, I have /usr on a separate partition for many years :-)
> >
> > > I'd suggest that you make sure that mount always gets statically linked
> > > against libblkid to avoid these problems.
> >
> > It's dynamically linked in many distributions without a problem.
>
> The problem that I saw was because of selinux going wild. Statically linking
Yes, I remember the bug (or bugs). Fixed now.
> would have avoided the problem for me, but I guess this is just one
> more reason for me to disable selinux and be done with it.
Frankly, it wasn't always easy to use SeLinux in previous FC
releases, but there is huge progress and I think it's much better in
FC6.
Karel
--
Karel Zak <[email protected]>
On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote:
> Frankly, it wasn't always easy to use SeLinux in previous FC
> releases, but there is huge progress and I think it's much better in
> FC6.
I've never tried SELinux, but at one point there were all sorts of
horror stories that if you enabled SELinux, the moment you installed
any 3rd party software packages, whether it's Oracle or Websphere or
some other commercial application program, the application would break
because of all sorts of SELinux policy violations, and that it
required an SELinux wizard to configure SELinux policy to enable a 3rd
party application to actually work correctly. Given that I tried
enabling SELinux, witnessed things break spectacularly and with no
hints about how to fix things, I've always had the attitude of "life
is too short to enable SELinux", and so my limited experience is
consistent with all of the horror stories that I've heard.
It sounds like SELinux has gotten better, according to your
description. Will handle arbitrary 3rd party software without running
wild, or is it still the case that the moment you want anything other
than software that was shipped with the distribution, it's "abandon
all hope, all ye who enter here"?
- Ted
On Wed, Dec 27, 2006 at 03:42:13PM -0500, Theodore Tso wrote:
> On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote:
> > Frankly, it wasn't always easy to use SeLinux in previous FC
> > releases, but there is huge progress and I think it's much better in
> > FC6.
>
> I've never tried SELinux, but at one point there were all sorts of
> horror stories that if you enabled SELinux, the moment you installed
> any 3rd party software packages, whether it's Oracle or Websphere or
> some other commercial application program, the application would break
> because of all sorts of SELinux policy violations, and that it
> required an SELinux wizard to configure SELinux policy to enable a 3rd
> party application to actually work correctly. Given that I tried
> enabling SELinux, witnessed things break spectacularly and with no
> hints about how to fix things, I've always had the attitude of "life
> is too short to enable SELinux", and so my limited experience is
The level of security is always your choice. The real security is
pretty expensive and you have to invest your time to make your system
really safe. IMHO people who provides simple and cheap solutions are
liars or marketing-agents or both.
For example for my laptop is it true that "life is too short to
enable SELinux", but it's probably not true for servers in the bank where
I have money. (I hope so:-)
> consistent with all of the horror stories that I've heard.
>
> It sounds like SELinux has gotten better, according to your
I'm really occasional selinux enduser only. So don't ask me for
details.
> description. Will handle arbitrary 3rd party software without running
> wild, or is it still the case that the moment you want anything other
> than software that was shipped with the distribution, it's "abandon
> all hope, all ye who enter here"?
There is possible customization of the existing selinux policy. You
can generate a new loadable policy module from system audit logs (see
audit2allow util). In the other words -- your system in the permissive
mode is monitoring your 3rd party software and from the logs you can
generate new selinux rules. And when you switch system to the
enforcing mode the application should be run as expected with your
new rules.
Karel
--
Karel Zak <[email protected]>
Karel Zak wrote:
>
> For example for my laptop is it true that "life is too short to
> enable SELinux", but it's probably not true for servers in the bank where
> I have money. (I hope so:-)
>
You'd be surprised how many banks run Windows, and not even the most
recent versions.
-hpa
On Wed, 27 Dec 2006, Theodore Tso wrote:
> On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote:
> > Frankly, it wasn't always easy to use SeLinux in previous FC
> > releases, but there is huge progress and I think it's much better in
> > FC6.
>
> I've never tried SELinux, but at one point there were all sorts of
> horror stories that if you enabled SELinux, the moment you installed
> any 3rd party software packages, whether it's Oracle or Websphere or
> some other commercial application program, the application would break
> because of all sorts of SELinux policy violations, and that it
> required an SELinux wizard to configure SELinux policy to enable a 3rd
> party application to actually work correctly. Given that I tried
> enabling SELinux, witnessed things break spectacularly and with no
> hints about how to fix things, I've always had the attitude of "life
> is too short to enable SELinux", and so my limited experience is
> consistent with all of the horror stories that I've heard.
I see the fine grained security of Selinux as a big problem for third
party applications.
It's a big job to make the OS work cleanly with it but the fact is that
many machines need to run significant 3rd party applications. I don't have
first hand experience but I suspect most vendors have tight enough budgets
without adding an Selinux developer and customers usually don't have this
resource either so, by and large, I expect people will just have to
disable it.
I really don't see any solution to this problem either.
Time will tell.
Ian
On Wed, 27 Dec 2006 23:12:51 +0100, Karel Zak said:
> For example for my laptop is it true that "life is too short to
> enable SELinux", but it's probably not true for servers in the bank where
> I have money. (I hope so:-)
On the other hand, the case can be made that your laptop needs SELinux *more*
than the bank servers - because the bank servers are (presumably) heavily
firewalled and stripped down software-wise, and otherwise hardened. But
your laptop is exactly one Firefox buffer overflow from being completely pwned...