On 2020-05-22 17:31, Steve Grubb wrote:
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.
Interesting. Where do you draw the line?
I guess /usr/lib*/python3.*/pydoc_data/topics.py is not data?
What about a YAML file? An Ansible playbook? A PostScript image?
A JavaScript file intended to be minified and sent to a browser?
Not that those are very practical questions. I'm just curious.
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?
Possible, but not easy. There's currently no clear distinction, and even
if you come up with a clear spec, it won't be easy to move all the files.
-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
