Requiring all files in /usr to be world-readable?

Richard W.M. Jones rjones at
Sat Nov 1 12:57:01 UTC 2014

On Fri, Oct 31, 2014 at 01:59:30PM -0400, Miloslav Trma─Ź wrote:
> ----- Original Message -----
> > I filed an FPC ticket:
> > 
> > Thoughts?

> My intuition is that if an application needs _everything_ in /usr to
> be readable then it is likely broken.  Something being placed in
> /usr does _not_ imply that it is supposed to be used by everyone.

That may be your intuition, but it's not a reason.  There are programs
which have long needed to read all - or many - files from /usr
(supermin being one, since around 2009).

> An administrator can come and change the permissions at any time,

Or they could delete RPM-managed files at random.  If that breaks
things, then that's a problem for the administrator.

> and the packaging guideline would not affect anything not included
> in Fedora-distributed RPMs.

supermin only looks at a subset of files, and only ones in (a subset
of) Fedora-distributed RPMs.

> And if we look only at the cases that
> would be helped by the proposed guideline, i.e. only depending on
> Fedora RPM-distributed files (but not being particular about what
> the purpose of kind of file this is), the application would probably
> be better off just opening and reading the RPMs from repos directly
> instead of reusing whatever local damage could have been done to the
> partition.

This is really slow, and requires network access.  supermin can build
an appliance from /usr in a few seconds, without needing network


> (And to the specific examples brought up: No opinion on systemd
> services; making setuid binaries not world-readable has a _definite_
> benefit when prelink is set up, OTOH that is no longer a default.)

Prelink should never have been modifying files in /usr in the first
place.  Thankfully as you say it's no longer the default.


Richard Jones, Virtualization Group, Red Hat
Read my programming and virtualization blog:
virt-builder quickly builds VMs from scratch

More information about the devel mailing list