tup only works with sudo ("setgroups: Permission denied")

[uohmak4fvpqe]

So I just upgraded to ubuntu 24.04.
Now, this is what I get :

$ tup
/proc/11285/setgroups: Permission denied
tup error: Unable to deny setgroups when setting up user namespace.
tup error: master_fork server did not start up correctly.

However, sudo tup works

[uohmak4fvpqe]

GPT and I have been investigating on that.
Turns out apparmor was making the trouble, and this solved the issue for me:

1. delete /etc/apparmor.d/tup or any file there named after tup
2. create the file /etc/apparmor.d/usr.local.bin.tup (adapt the filename and file content to your tup path):

#include <tunables/global>
"/usr/local/bin/tup" {
  #include <abstractions/base>
  capability sys_admin,
  mount,umount,
  /** rwk,
  /** ix,
}

3. run sudo apparmor_parser -r /etc/apparmor.d/usr.local.bin.tup

This basically allows everything tup might have requested for during my tests.
in case I missed anything and you have tup complain about missing rights, you can then run aa-notify -s 1 -v to see what was denied and tune the file above

[danielytics]

I had to add flags=(attach_disconnected) to mine to make it work:

#include <tunables/global>
"/usr/local/bin/tup" flags=(attach_disconnected) {
  #include <abstractions/base>
  capability sys_admin,
  mount,umount,
  /** rwk,
  /** ix,
}

I don't really know anything about AppArmor so I don't know why I needed it and why that worked, but in case other people are having trouble getting it to work, adding that worked for me.

This is what I saw in journalctl -xe before adding it:

Jul 23 10:16:26 mosi kernel: audit: type=1400 audit(1721726186.039:4133): apparmor="DENIED" operation="getattr" class="file" info="Failed name lookup - disconnected path" error=-13 profile="/usr/local/bin/tup" name="home/dan/foo/.tup/tmp/>```

[athajaerel]

Ubuntu 22.04 LTS "Jammy".

I have the exact same error message. Nothing tup-related in the journalctl log.

I followed the suggestion above and added the flag, but it didn't help.

My tup is in /usr/bin rather than /usr/local/bin, but I made that change to the AppArmor config above.

If it's any use, here is my aa-notify output:

Profile: /usr/bin/tup
Operation: capable
Name: dac_override
Logfile: /var/log/kern.log

Profile: /usr/bin/tup
Operation: capable
Name: dac_override
Logfile: /var/log/kern.log

Profile: /usr/bin/tup
Operation: capable
Name: dac_override
Logfile: /var/log/kern.log

I don't know how to progress this. Just to get some work done, I'll switch to make. (Ugh.)

[petemoore]

This version worked for me (/etc/apparmor.d/tup):

abi <abi/4.0>,
include <tunables/global>

profile tup /usr/local/bin/tup flags=(complain) {
    userns,
    capability sys_admin,  # Allow system administrator capabilities in user namespaces
    # Site-specific additions and overrides. See local/README for details.
    include if exists <local/tup>
}

I've no idea how good/bad that is, just a ChatGPT solution in my case 😬 .

Note, I needed to reload after making changes with sudo apparmor_parser -r /etc/apparmor.d/tup.

[aherrmann]

I encountered the same issue with an instance of tup installed via Nix on Ubuntu 24.04. In that case the issue was not the lack of additional capabilities in the apparmor configuration, but rather that the default file pattern (/usr/bin/tup) did not apply. I added a dedicated apparmor configuration for a Nix provided tup to /etc/apparmor.d/tup/tup-nix:

abi <abi/4.0>,
include <tunables/global>
profile tup /nix/store/*/bin/tup flags=(unconfined) {
  userns,
  include if exists <local/tup>
}

After reloading via sudo apparmor_parser -r /etc/apparmor.d/tup-nix tup worked again.

[petemoore]

ah, maybe flags=(unconfined) already implies capability sys_admin?