----- Original Message ----- > On Fri, Oct 31, 2014 at 01:59:30PM -0400, Miloslav Trmač wrote: > > ----- Original Message ----- > > > I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 > > > > > > 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. OK, then let me write it more precisely: that application is relying on a property that was never documented or promised to be true. > There are programs > which have long needed to read all - or many - files from /usr > (supermin being one, since around 2009). Yes, I was specifically thinking of supermin as an example. > > An administrator can come and change the permissions at any time, > > Or they could delete RPM-managed files at random. Unlike deleting RPM-manged files at random, the administrator is can reasonably expect that creating more files and giving them whatever permissions they feel appropriate, both in /usr/local and in anything else they decide to place into /usr and package, will work and not break the OS. > > 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 > access. That’s a cool hack when it works, but it is not promised to work so the burden on handling the case when it doesn’t is (at least as /usr is currently defined) on supermin, and I’m not convinced that speeding up supermin is worth limiting the use cases of /usr. The primary purpose of /usr is storing components of running applications and the operating system, not a self-replicating distribution mechanism. And as for “everything is available in RPMs anyway”, 1) not all RPMs are publicly available, and 2) the argument about it being slow and requiring network access equally applies here. There _is_ a security benefit to an unprivileged attacker not knowing what the system’s policy is, and note that this doesn’t require modifiable state: it also includes drop-in files modifying the default policy, and packaged within (often site-specific) RPMs. The current (unstandardized BTW) push to move default configuration away from /etc into /usr naturally means that this drop-in default configuration should both be packaged as inaccessible to unprivileged users, and located in /usr. Mirek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
