Local users in autopkgtest hosts

[Daniel Markstedt]

Hi Debian devs,

I would like to ask your advice concerning autopkgtest.
At the moment, I'm preparing to set up an automated test suite for the "netatalk" package.
Netatalk is a file server daemon that you need to authenticate with through user credentials.
So in order to run end to end tests, one need to know the credentials of a user on the host:
Either an existing user's, or by creating new users on the fly.

My question is: How would one go about doing either of the above on the autopkgtest runner hosts?
I don't want to start running `useradd' before confirming that this is allowed,
and/or if there is a more sophisticated way to achieve my goals.

Thank you!

Daniel

[Colin Watson]

Post by Daniel Markstedt
I would like to ask your advice concerning autopkgtest.
At the moment, I'm preparing to set up an automated test suite for the "netatalk" package.
Netatalk is a file server daemon that you need to authenticate with through user credentials.
Either an existing user's, or by creating new users on the fly.
My question is: How would one go about doing either of the above on the autopkgtest runner hosts?
I don't want to start running `useradd' before confirming that this is allowed,
and/or if there is a more sophisticated way to achieve my goals.

Declaring "Restrictions: needs-root", running adduser or similar, and
then dropping privileges to run the actual test is fine and sounds quite
reasonable in this case. It'll all be done within the relevant testbed
and thrown away at the end of the test. For example, openssh does
something similar.

I suggest reading /usr/share/doc/autopkgtest/README.package-tests.html
for the exact semantics of needs-root.

[Daniel Markstedt]

Post by Colin Watson

Post by Daniel Markstedt
I would like to ask your advice concerning autopkgtest.
At the moment, I'm preparing to set up an automated test suite for the "netatalk" package.
Netatalk is a file server daemon that you need to authenticate with through user credentials.
Either an existing user's, or by creating new users on the fly.
My question is: How would one go about doing either of the above on the autopkgtest runner hosts?
I don't want to start running `useradd' before confirming that this is allowed,
and/or if there is a more sophisticated way to achieve my goals.

Declaring "Restrictions: needs-root", running adduser or similar, and
then dropping privileges to run the actual test is fine and sounds quite
reasonable in this case. It'll all be done within the relevant testbed
and thrown away at the end of the test. For example, openssh does
something similar.
I suggest reading /usr/share/doc/autopkgtest/README.package-tests.html
for the exact semantics of needs-root.
--

Hi Colin,

Thanks you for sharing your advice. With this context I was able to make sense of the documentation.
In the end, I went with the "needs-sudo" restriction instead, to be able to run the actual test suite as non-root.

I'm using Perl and the Test::Simple module as the runner, and couldn't figure out how to drop to non-root when using the "needs-root" restriction.
I attempted setting the AUTOPKGTEST_NORMAL_USER environment variable subsequently in the Perl script, but it didn't take any effect with this particular test runner.

Anyways, I have a working test suite locally now, so this is just a note for the record!

Sincerely,
Daniel

[Simon McVittie]

Post by Daniel Markstedt
In the end, I went with the "needs-sudo" restriction instead, to be
able to run the actual test suite as non-root.

That's often a good choice if only a minority of your test needs to
do privileged things. gvfs is one of the canonical examples of this:
it uses its sudo access to set up a Samba server to test against, but
then runs the actual test as the non-root user.

Post by Daniel Markstedt
I'm using Perl and the Test::Simple module as the runner, and
couldn't figure out how to drop to non-root when using the "needs-root"
restriction.

Any of the same ways you might drop to non-root in production code should
work (for example running commands wrapped in runuser, setpriv or sudo,
or calling POSIX::setuid or similar). There is nothing particularly special
about autopkgtest here.

Post by Daniel Markstedt
I attempted setting the AUTOPKGTEST_NORMAL_USER environment variable
subsequently in the Perl script, but it didn't take any effect with this
particular test runner.

That isn't how that environment variable works, and I'm not aware of
any way that setting an environment variable could change your uid
as a side-effect. It works the other way round: it isn't how you tell
autopkgtest to change to the normal user, it's how autopkgtest tells
your test-case a normal user that you might want to use.

Specifically, if your test was run as root via the needs-root restriction,
and you want to drop privileges to a non-root uid by whatever mechanism
is most appropriate for your test (runuser or POSIX::setuid or whatever),
then $AUTOPKGTEST_NORMAL_USER is the username of a non-root uid that
autopkgtest suggests as being appropriate for that purpose.

smcv