Package: autopkgtest
Version: 5.5
Severity: wishlist
The test suite for gvfs needs to run as an unprivileged user, but also
needs to escalate privileges to be root-equivalent. It does this by using
sudo, but it could equally be using pkexec or similar. I think I've seen
other packages with similar behaviour.
Ubuntu cloud VM images have an 'ubuntu' user that is already
root-equivalent, but test images created by other means, for example
the vmdebootstrap invocation in the autopkgtest-virt-qemu man page,
do not necessarily have a root-equivalent user.
At the moment, the gvfs test fails on a VM created according to the
autopkgtest-virt-qemu man page, but can be made to (mostly) succeed by
adding the normal user to the sudo group and enabling passwordless sudo.
I think we should consider a restriction like needs-root-equivalence or
needs-sudo or similar, something like this:
needs-sudo
The test script must be run as a non-root user that is a member of
the sudo group (as defined by base-passwd), and has the ability to
escalate privileges to root by running ``sudo -n`` (see sudo(8)).
The test runner also behaves as though the sudo package had included
in the test's Depends field. (TODO: Do this, or require sudo to be
added to Depends explicitly if it will be used?)
When using other packages that provide special privileges for members
of the sudo group, such as policykit-1 and flatpak, the test may
assume that this root-equivalent behaviour is provided.
Unlike the ``needs-root`` restriction, this has the effect that the
non-root user is in a properly set up login session for their own
uid, which is significant for some packages, for example those that
make authorization decisions based on systemd-logind sessions.
Implementation:
- if we do not have the suggested-user capability:
- skip
- else if we have the revert-full-system and root-on-testbed capabilities:
(e.g. qemu runner)
- add the suggested-user to the sudo group
- install sudo (?)
- create /etc/sudoers.d/autopkgtest-needs-sudo with content
"%sudo ALL=(ALL:ALL) NOPASSWD: ALL" and correct (0444) permissions
- run the tests
- else if the suggested-user is already in the sudo group:
(null or ssh runner)
- if sudo -n -v succeeds:
- run the tests
- else:
- skip
- else:
- skip
Regards,
smcv
