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

Andrew Lutomirski luto at
Fri Oct 31 18:30:20 UTC 2014

On Fri, Oct 31, 2014 at 10:59 AM, Miloslav Trma─Ź <mitr at> 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.   An administrator can come and change the permissions at any time, and the packaging guideline would not affect anything not included in 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.

I'm fine with having various user tools that want to read from /usr
stop working as non-root if the admin changes the permissions.  But I
think they should work by default.

> Perhaps there are useful subsets of files in /usr where mandating this would be useful; but all of /usr is seems like an unnecessary overreach.

That's why I think that individual exceptions should be allowed.  I
don't yet know of a case where I would agree that an exception would
be a good idea, but I don't want to rule it out.

> (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.)

I certainly agree with the prelink issue, but I think that that issue
is obsolete.  There's already a guideline stating that suid binaries
MUST be PIE, and the guideline claims (hopefully correctly) that
prelink doesn't work for PIE executables, so there shouldn't be any
prelinked suid binaries in the first place.


More information about the devel mailing list