Hi,
I recently added a new step in my ansible playbook to ran sysupgrade on batch of
hosts: it install a temporary /etc/nologin to prevent users to log-in while
sysupgrade is fetching sets.
Now, I am seeing unveil(2) violation in acct(2) log file:
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:01:32.50)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:00:00.48)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:00:01.75)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:00:03.75)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:00:02.17)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:00:00.88)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:00:00.34)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:00:06.67)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:00:01.03)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:00:02.16)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:01 (0:00:01.94)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:00 (0:01:31.27)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:00 (0:00:00.05)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:00 (0:00:00.06)
sh -U _syspatch __ 0.00 secs Thu
Aug 6 16:00 (0:00:00.14)
For now, I think there is several bugs.
The first one is the offender reported in acct subsystem is "sh", whereas the
real offender is "su". I am suspecting a race, but I will look at it later.
Regarding the unveil(2) violation, su(1) needs to unveil("/etc/nologin") in
order to know that users without ignorelogin knob (see login.conf(5)) shouldn't
be allowed to log-in.
The following diff do that:
diff a17537c08dc233ec23b087c648b5643d2f8e5eb3 /home/semarie/repos/openbsd/src
blob - a4cd0e0a77ab6bff8e358aa575b50f2a42199d92
file + usr.bin/su/su.c
--- usr.bin/su/su.c
+++ usr.bin/su/su.c
@@ -170,6 +170,8 @@ main(int argc, char **argv)
err(1, "unveil");
if (unveil(_PATH_DEVDB, "r") == -1)
err(1, "unveil");
+ if (unveil(_PATH_NOLOGIN, "r") == -1)
+ err(1, "unveil");
for (;;) {
char *pw_class = class;
Please note that with that, /etc/nologin is respected, but sysupgrade(8) or
syspatch(8) will fail if /etc/nologin is present:
# su -s /bin/sh _syspatch -c 'id'
uid=112(_syspatch) gid=112(_syspatch) groups=112(_syspatch)
# echo test >/etc/nologin
# su -s /bin/sh _syspatch -c 'id'
su: approval failure: Undefined error: 0
It fails because _syspatch user belongs to 'default' class, and 'default' has
ignorenologin set to false by default.
So I wonder if _syspatch user should be in 'daemon' class (or something new for
system user without the need of lot of ressources).
Thanks.
--
Sebastien Marie