Date: Sun, 30 May 2021 01:57:10 +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-8jQO2K8QC5@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 #2 from bugs.freebsd@scourger.nl --- Thanks for the quick reply. I've done a little bit of extra testing, and ca= me up with some points and opinions. Regarding su, doas actually doesn't behave in the same way as su in my test= s. While su also ignores the target user's login class, it does keep the capabilities of the caller intact. Conversely, doas applies capabilities fr= om 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=3Den_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 lo= gin class. This difference in behaviour came somewhat as a surprise to me. 2. Interestingly, OpenBSD doesn't let you run "doas ulimit" (another surpri= se). But "doas -u bob sh" seems to indicate that limits from bob's login class a= re applied. 3. On OpenBSD, behaviour between doas and su is consistent. Note: apparently OpenBSD doesn't let you configure "lang" in /etc/login.con= f, 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, whi= ch I'd consider incorrect in any case. * For me personally, I'd prefer the same behaviour as on OpenBSD (apply tar= get 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 m= akes 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. --=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-8jQO2K8QC5>