Open ermo opened 1 year ago
ACL isn't really the issue here, we support that and apply it on fs generation. The issue comes from the potential for two packages specifying different permissions for the same unique underlying file. It hasn't cropped up yet so is unhandled.
The issue in this build is that the man
user doesn't exist in the build environment. Therefore chown
etc are limited
to explicit UIDs. This is not something that is really remediable until moss-triggers + user management are integrated.
However I'd argue it's an environment problem not a format one.
Re: setuid usage, I'm not fond of it. I would sooner wait until moss supports xattrs and handle it properly.
However I'd argue it's an environment problem not a format one.
I'd argue that it is both (though I am aware that we have had discussions on how to capture non-default file attributes/ ACLs), given that we also need to develop a story around xattrs as you said.
The issue is here as both a sort of summary and so we don't forget about it in the flurry of activity in our short and medium term future.
The points you made are obviously noted for the future as well.
We deduplicate assets prior to storing them in a moss-format archive. On
moss install
, we generate a FS transaction with hardlinks to the asset store in order to cut down on duplication.Consider the following:
From the above, it is crystal clear that modifying hardlinked assets is a transitive operation that also applies to the original asset.
Therefore, any and all metadata manipulation (which deviates from a set of defined defaults) MUST be:
a. done during
boulder build
AND b. be considered immutable from that point onThis has the following implications:
root
runningmoss
in the period where it is not mounted RO (Path based LSM such as TOMOYO or AppArmor ?)boulder build
ANDAs an example, @joeyriches ran into an interesting issue regarding man pages, which looked like this: