serpent-os / libmoss

Unified moss modules - internal API
4 stars 5 forks source link

How to handle ACLs and (extended?) file attributes in moss-format #13

Open ermo opened 1 year ago

ermo commented 1 year ago

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:

ermo@dante:~
$ echo 'This is a source-file' > source-file
ermo@dante:~
$ ln source-file copy-1
ermo@dante:~
$ ln source-file copy-2
ermo@dante:~
$ ls -l source-file copy-1 copy-2
-rw-r--r-- 3 ermo ermo 30 Jan 16 17:49 copy-1
-rw-r--r-- 3 ermo ermo 30 Jan 16 17:49 copy-2
-rw-r--r-- 3 ermo ermo 30 Jan 16 17:49 source-file
ermo@dante:~
$ chown :users copy-1
ermo@dante:~
$ ls -l source-file copy-1 copy-2
-rw-r--r-- 3 ermo users 30 Jan 16 17:49 copy-1
-rw-r--r-- 3 ermo users 30 Jan 16 17:49 copy-2
-rw-r--r-- 3 ermo users 30 Jan 16 17:49 source-file
ermo@dante:~
$  chmod g+w copy-2
ermo@dante:~
$ ls -l source-file copy-1 copy-2
-rw-rw-r-- 3 ermo users 30 Jan 16 17:49 copy-1
-rw-rw-r-- 3 ermo users 30 Jan 16 17:49 copy-2
-rw-rw-r-- 3 ermo users 30 Jan 16 17:49 source-file
ermo@dante:~
$ 

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 on

This has the following implications:

  1. /usr MUST be mounted RO during normal operations
  2. /usr MUST be protected from access from anyone but root running moss in the period where it is not mounted RO (Path based LSM such as TOMOYO or AppArmor ?)
  3. Our tooling MUST capture non-standard metadata in the moss-format binary archives during boulder build AND
  4. Our tooling MUST adhere to/respect the non-standard metadata

As an example, @joeyriches ran into an interesting issue regarding man pages, which looked like this:

* Joey Riches sighs

if [ "man" ] && [ "6755" = 6755 ]; then \
        chown man:man \
                /mason/build/install/usr/bin/man \
                /mason/build/install/usr/bin/mandb; \
fi
chown: invalid user: ‘man:man’

Joey Riches make install of man-db patch it out? ok got it (--disable-setuid)

ikeycode commented 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.

ermo commented 1 year ago

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.