Maintaining file permissions

Help
1

I need to modify file permissions of a k3s file and I found this way to do it:

  systemd.tmpfiles.rules = [
    "f /etc/rancher/k3s/k3s.yaml 0640 root wheel -"
  ];

Problem is: Seems like I need to manually run

sudo systemd-tmpfiles --create

so it gets applied.

I might be missing something here.
Any pointers?

1 Like
2

/etc isn’t a tmpfile, so it makes sense why this does not work. are you creating this file with nix? is it symlinked from the store?

3

I had a similar thought - but I am wondering how systemd would know.

Plus, when triggering via sudo systemd-tmpfiles --create it does change the permissions and ownerships.

The original file gets created by the k3s package.

1 Like
4

systemd is PID1, it knows all :wink:

there is an option to specify the location of the config file, perhaps the module needs an update to include permissions on the file.

5

systemd-tmpfiles is used not only for temp files, but for (at least some) system and user files/directories too

2 Likes
6

as a crutch, if you won’t end up finding another solution, you can just add
systemd-tmpfiles --create
in your system.activationScripts

2 Likes
7

You mean like native support of the k3s package? That certainly would be nice.

8

are you not using some of the options? NixOS Search

9

I sure am - but there is no way to specify permissions or ownerships of the file AFAICS.

10

is wheel needed so you can edit the file? or something else?

11

So users in group wheel can read the file.

12

When the tmpfiles rules are changed, NixOS should automatically restart systemd-tmpfiles-resetup.service which runs systemd-tmpfiles --create --remove --exclude-prefix=/dev. Check whether this service properly triggers upon activation.

You said you use this rule to modify the file permissions which implies the file already exists; who creates the file? That’d be the best place to set the policy for the file’s permissions.
You might also simply be running into a race condition where the file is created (or re-created) after the systemd-tmpfiles-resetup.service runs.

13

We’re not talking about systemd here. This is systemd-tmpfilesd which is an entirely separate program and does not share state with systemd. As far as it’s concerned, it doesn’t care whether systemd (PID1) is present or not.

Contrary to popular belief, the systemd project is not a monolith.

14

This is what I am seeing

$ systemctl status systemd-tmpfiles-resetup.service
â—‹ systemd-tmpfiles-resetup.service - Re-setup tmpfiles on a system that is already running.
     Loaded: loaded (/etc/systemd/system/systemd-tmpfiles-resetup.service; enabled; preset: enabled)
     Active: inactive (dead)

$ systemctl status systemd-tmpfiles-setup.service 
â—Ź systemd-tmpfiles-setup.service - Create Volatile Files and Directories
     Loaded: loaded (/etc/systemd/system/systemd-tmpfiles-setup.service; enabled; preset: enabled)
     Active: active (exited) since Mon 2024-07-01 14:21:25 UTC; 6h ago
       Docs: man:tmpfiles.d(5)
             man:systemd-tmpfiles(8)
    Process: 582 ExecStart=systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=0/SUCCESS)
   Main PID: 582 (code=exited, status=0/SUCCESS)
         IP: 0B in, 0B out
        CPU: 35ms

Jul 01 14:21:25 foo systemd[1]: Starting Create Volatile Files and Directories...
Jul 01 14:21:25 foo systemd-tmpfiles[582]: /etc/tmpfiles.d/tmp.conf:11: Duplicate line for path "/tmp", ignoring.

k3s creates that file - but I am not sure how often it gets modified.

And unless the packages gets changed there is no way to (that I see) to enforce a certain permission/ownership.

How often gets the filesystem checked is what I am wondering.

15

Did you activate a generation where the tmpfiles rules differ from the previous generation? Resetup only gets started in that specific case.

You will need to figure this out. It’s likely the crux.

Though note that modification is not the important bit but explicit direct metadata modification or implicit indirect metadata modification (by replacing the file(=inode) with an entirely new one).

Have you checked in with upstream about this?

Whenever one of these services is started:

  • systemd-tmpfiles-setup.service
  • systemd-tmpfiles-setup-dev.service
  • systemd-tmpfiles-setup-dev-early.service
  • systemd-tmpfiles-resetup.service

The first three should only start once. The last is started as described above.

Another option you may want to consider is to change the umask of k3s which affects the permissions it’ll create new files with. Though this affects all files it writes, so it might also affect files other than this config file.

Yet another option (though I personally don’t like it) could be to use ACLs. Though again, if the file is deleted and re-created, they likely won’t help you either.

16

Oh, OK. Then “resetup” really isn’t of any help here.

I’ve only checked services.k3s - MyNixOS but it seems like this just gets passed into k3s so it’s not really a NixOS concern I guess.

It would really have to be set by k3s.

I thought it would be a service executed on a schedule to ensure permissions/ownership.

That sounds like a can of worms I rather not touch :slight_smile:

Much appreciate the help!