> A recent customer bug report revealed that we have packages in the standard
> Ubuntu system (mtr-tiny) which are making use of filesystem capabilities, to
> reduce the need for suid binaries on the system:
> $ getcap /usr/bin/mtr-packet
> /usr/bin/mtr-packet = cap_net_raw+ep
> The customer bug report arose because today, we are not handling all Ubuntu
> images in an xattr-safe manner. E.g., on a freshly-launched cosmic lxd
> container here:
> $ lxc exec caring-calf -- getcap /usr/bin/mtr-packet
> This prevents the software from working as intended by the Debian
> maintainer; the command will only succeed as root in such an environment,
> where it is intended to be runnable as a non-root user.
> We have previously dealt with such an incompatibility in the iputils package
> by introducing an Ubuntu delta
> (https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1302192), restoring
> use of suid in place of fscaps. This is suboptimal because:
> - It violates the principle of least privilege; why give processes full
> root privs if cap_net_raw is all they need?
> - It's a game of whack-a-mole. We fixed iputils in response to bug
> reports, but the wrong privileges on mtr-packet went unnoticed. There
> may be other bugs in the future again caused by failing to preserve
> I am therefore proposing that we explicitly raise the requirements for
> Ubuntu root filesystems to always be transported in an xattr-preserving
For the cases when one forgets to unpack with extended attributes, the
packages in question imho should ship a tmpfiles.d snippet such that
these extended attributes are restored on boot (if that given
filesystem is ever booted).
t /run/cups - - - - security.SMACK64=printing user.attr-with-spaces="foo bar"
For more details see
It would be even useful imho to add a lintian check for this.
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel