On Friday, May 22, 2020 10:39:43 AM EDT Petr Viktorin wrote: > On 2020-05-22 16:30, Steve Grubb wrote: > > Hello, > > > > I am working on our application whitelisting daemon. It uses the rpmdb to > > derive trust in what's on disk. If we use the whole rpmdb, then the > > number of files is large. So, to prune the amount of entries in the > > trust db down to a reasonable number, I thought we could jettison > > anything in /usr/share. > > > > According to the Filesystem Hierarchy Standard [1] it says this about > > /usr/ share: > > > > The /usr/share hierarchy is for all read-only architecture independent > > data files. > > > > But what I'm finding in practice is that cinnamon places its javascript > > there, there are libexec dirs that contain executable code, there are > > python and byte compiled python over there. In short, the system doesn't > > work because critical executables are in /usr/share. > > > > The question is what should be done about this? Do we care that things > > are in /usr/share that are not following the Filesystem Hierarchy > > Standard? If we do, what is the proper fix this this? Should bz be > > opened against each component? > > Does "read-only architecture independent data" mean the files must not > be programs? I personally think of data and applications/modules/libraries as distinct entities. > Javascript, Python scripts and Python bytecode are all read-only and > architecture independent. But they are not data. What I'm trying to do is constrain the notion of what can be executed. > And everything on disk is data. > The document you linked explicitly gives troff macros and "perl" as > examples of what goes in /usr/share/. Indeed it does. But it also suggests /usr/lib as another home for that. If there was a /usr/share/code or /usr/share/perl or some convention like that, it would make the job easier because applications are discoverable. Instead they are hidden and in unexpected places. And its hard to tell what are example programs from something that the system depends on. There needs to be clarity about the intentions of any system code that lives in /usr/share. At least the libexec dirs are obvious. Is it possible to make this system code discoverable? -Steve > IMO, /usr/share/ would be a better place for *all* pure-Python modules > than /usr/lib/, where they are now. The main reason they weren't moved > is that the move would cause a lot of disruption. > > > 1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
