Yeah, that would be simple, although maybe someone is counting on
those users to exist later. We could create special users on the
system for the purpose of this test that didn't exist before the test
(and delete them afterward), but then there are other setup/cleanup
questions, like:

- Do we unmount securityfs after the test? What if something was
counting on it being mounted or not mounted?
- Do we flush the SafeSetID LSM policies after the test? Note that the
LSM doesn't currently have the functionality to flush individual
policies, so what happens if something was counting on certain
policies (for other users) being configured for the LSM and we flush
those after running our test?

These questions were the reason I was hoping to get more info on the
kind of environment in which these selftests run. If the norm is to
boot up a VM, run one of these tests, then reboot/shutdown, most of
these questions don't need to be answered (we would still probably
want to fix user creation/deletion since that is persistent across
reboots).

On Wed, Feb 6, 2019 at 11:26 AM Edwin Zimmerman [off-list ref] wrote:

quoted

On Wednesday, February 06, 2019 2:03 PM Micah Morton wrote:

quoted

This patch adds a selftest for the SafeSetID LSM. The test requires
mounting securityfs if it isn't mounted, creating test users in
/etc/passwd, and configuring policies for the SafeSetID LSM through
writes to securityfs.

Signed-off-by: Micah Morton <mortonm@chromium.org>
---
This test is reasonably robust for demonstrating the functionality of
the LSM, but is no masterpiece by any means. I'm not totally sure how
these tests are used. Are they incorporated into testing frameworks for
the Linux kernel that are run regularly or just PoC binaries that sit in
this directory more or less as documentation? If its the former, this
code probably needs some more cleanup and better organization. Beyond
coding style, the test doesn't bother to clean up users that were added
in /etc/passwd for testing purposes nor flushes policies that were
configured for the LSM relating to those users. Should it?

No good reason to leave the users, so I would suggest cleaning them up.
All it would take would be several deluser commands
in safesetid-test.sh.  Very simple.