[Bug 256233] security/doas: target user's login class gets ignored

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256233

--- Comment #2 from bugs.freebsd@scourger.nl ---
Thanks for the quick reply. I've done a little bit of extra testing, and came
up with some points and opinions.

Regarding su, doas actually doesn't behave in the same way as su in my tests.
While su also ignores the target user's login class, it does keep the
capabilities of the caller intact. Conversely, doas applies capabilities from
the "default" class.
To demonstrate that su just leaves the caller's limits intact:
alice@doas-bug:~ $ su bob -c 'ulimit -m'
Password:
8388608
alice@doas-bug:~ $ su bob -c 'locale | grep LANG'
Password:
LANG=en_CA.UTF-8

## On OpenBSD

To compare what happens on OpenBSD, I have done a clean install of OpenBSD 6.9
(in a VM) with similar limits configured for alice and bob. This yields some
interesting results:
alice@openbsd $ ulimit -m
8388608
alice@openbsd $ su bob -c 'ulimit -m'
4194304
alice@openbsd $ doas -u bob ulimit -m
doas: ulimit: command not found
alice@openbsd $ doas -u bob sh
bob@openbsd $ ulimit -m
4194304

1. In contrast to FreeBSD, su also applies limits from the target user's login
class. This difference in behaviour came somewhat as a surprise to me.
2. Interestingly, OpenBSD doesn't let you run "doas ulimit" (another surprise).
But "doas -u bob sh" seems to indicate that limits from bob's login class are
applied.
3. On OpenBSD, behaviour between doas and su is consistent.

Note: apparently OpenBSD doesn't let you configure "lang" in /etc/login.conf,
so it has been omitted here.

## My opinion

All things considered, this is my take on the issue:
* By default, doas should either apply the target user's login class (as is the
case on OpenBSD) or keep the capabilities of the caller (like su on FreeBSD).
In the current situation doas always applies the "default" login class, which
I'd consider incorrect in any case.
* For me personally, I'd prefer the same behaviour as on OpenBSD (apply target
user's login class). A clear downside of this approach is that it would make
doas inconsistent with su. But in my opinion, OpenBSD's su behaviour also makes
more sense (apply target user's limits) compared to FreeBSD.
* I do not consider it likely that the behaviour of su on FreeBSD will be
changed anytime soon, so changing doas to just keep the callers capabilities
seems like a very reasonable thing to do. This way, doas and su work
consistently. Depending on who you'd ask, this could be intended behaviour or
still not correct.
* As for "doas -S", I think it should indeed be identical to "su -l".

This whole issue does make me wonder about the proper/intended behaviour of su.

-- 
You are receiving this mail because:
You are the assignee for the bug.