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

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

--- Comment #1 from jsmith@resonatingmedia.com ---
I've looked into this a little bit and confirmed the behaviour described in the
issue report is reproducible on my FreeBSD machines. The login class of the
target user is indeed ignored when using "doas -u username". Thank you for the
detailed problem description.

While looking into this I gave some thought as to how doas is working,
particularly in comparison to other tools. For instance, when I run the "su"
command to run a shell or command as another user, it behaves the same way as
doas.

As an example, if I run "su alice" and then run "ulimit -a" as Alice her login
class limits are ignored. However, if I run "su - alice" it triggers an
effective wipe/fresh login action and when I run "ulimit -a" as Alice then her
login class is in effect.

In short, at least where the "su" utility is concerned, login classes only seem
to matter when we're forcing a fresh login, not when we're simply switching
accounts/permissions to another user. The default behaviour of su on my FreeBSD
machine is to ignore the login class (and limits) of the user.

Which makes me wonder which behaviour makes more sense for doas? Should it act
like the default "su" behaviour and simply switch user permissions or should it
act as though it is performing a fresh login for the new user?

While considering this I noticed that running "doas -S -u alice", which is
supposed to simulate a fresh login, also doesn't respect the user class and
/etc/login.conf settings. Which makes me think the best way to approach this
would be to:

1. Leave the default behaviour as it is, to match su.
2. Fix "doas -S" to properly simulate a full login, similar to running "su -"
which would appear to best match the upstream doas manual page.

I'm open to thoughts and feedback on this idea.

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