Date: Sat, 29 May 2021 15:15:49 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 256233] security/doas: target user's login class gets ignored Message-ID: <bug-256233-7788-5IpiXTrjec@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-256233-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-256233-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256233 --- 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 lo= gin 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 Fre= eBSD 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 shoul= d 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-256233-7788-5IpiXTrjec>