F43 Change Proposal: Hardlink identical files in packages by default (self-contained)

Project Discussion Change Proposals
,
21

Thank you for the script.

return subprocess.run(["stat", "--format=%C", file],
capture_output=True, check=True). \
stdout.decode().strip()

I guess this could be replaced by pyxattr:

import xattr
xattr.getxattr(file, 'security.selinux').rstrip(b'\0').decode()

This version finds 208 problematic cases.

It seems that those cases are result of automatic labelling for different directories: lib_t for /usr/lib* vs. usr_t for the rest of /usr, locale_t for anything under /usr/share/locale, etc. I expect that those changes in context would not cause AVCs
 For example, programs generally need to be able to read files under /usr, so they’ll be able to read locale files too.

But the problem could be that restorecon could set the context one way or the other way depending on which hardlink it looks at, and then flip back-and-forth between them. Hmmm. I think we’d want a few different solutions here:

  • for the mingw locale files, we could add a context path equivalency so that they get labelled with locale_t too.
  • same for the other locale files in strange locations (do those even work?)
  • otherwise, we might need to not link files that cross the /usr/share — /usr/lib “boundary”.

I’m open to better ideas :wink:

22

Thanks for the Python xattr pointer!

For locale files in non-standard places I completely agree, it is most likely more correct to label them locale_t.

Out of curiosity I tried to compare the permissions allowed for locale_t with those allowed for usr_t. (I ran sesearch -A -t locale_t and usr_t and then diff:ed the results.) A common theme seems to be that usr_t files can be executed, but locale_t files can not. I guess a file that lives in both places should never be executed, so that shouldn’t be a problem (perhaps depending on how paranoid you are).

Separating /usr/share from /usr/lib* might be a good heuristic that catches most of the cases, but there would probably still be some odd cases that doesn’t work. On my test system docbook-style-xsl seems to be a case where it wouldn’t help.

I can’t think of any good solution. Nothing short of checking everything hardlink did with matchpathcon, and undo the link if the types don’t match. Or try to modify hardlink to do it. Neither idea feels very tasty.

I’m sorry I don’t have any more constructive ideas. I really do like the proposal and would enjoy seeing it implemented.