Date: Sun, 30 May 2021 15:37:41 +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-H6qtBU8l0Q@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 #3 from jsmith@resonatingmedia.com --- Thank you for looking into this further. I did some looking about in the code and manual pages and discovered the is= sue. FreeBSD has a "class" field in the password structure which doesn't exist in other supported platforms. Since it's a FreeBSD-ism it wasn't a field which= was set/checked in the code. Which meant when class resources were being set in setusercontext() the class field would be blank and the system would just s= et the defaults. This has been changed upstream. When getting the password data doas will now check if it is running on FreeBSD and, if so, copy the class field and use = it when applying login rules/limits. I've tested this on FreeBSD 12.2 and confirmed restrictions like max memory usage are being applied. The fix is now in the GitHub repo: https://github.com/slicer69/doas This was a small fix, just two lines in two files (doas.c and env.c). If you could give the fixed code a test run and confirm it's using the proper limi= ts from the target that would be very helpful. Assuming it works and I don't r= un into any problems on my other test systems, I'll publish a new version with= the fix. --=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-H6qtBU8l0Q>