Date: Tue, 04 Jun 2019 15:52:49 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 238319] login: Extend and add features to session (struct) Message-ID: <bug-238319-227-aJ0FWA74BT@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-238319-227@https.bugs.freebsd.org/bugzilla/> References: <bug-238319-227@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=3D238319 Conrad Meyer <cem@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cem@freebsd.org --- Comment #1 from Conrad Meyer <cem@freebsd.org> --- Re: (1): s_login is only modified by setlogin(2), which requires PRIV_PROC_SETLOGIN, which ... is always permitted for the current process on its session. Each time it is set, it produces an audit record, AUDIT_ARG_LOGIN(). You could conceivably add a flag to session 'has_login_been_set', set it as appropriate, and check it in priv_check PRIV_PROC_SETLOGIN under secureleve= l.=20 But why? What does it mean to restrict setlogin(2) to "new" sessions? Users can alw= ays just create a new process and make it the new session leader (setsid() or setpgid()). The old process gets a new "login" on its associated session. Re: (2): I don't think this metadata makes much sense in session. It's out of line = with existing session metadata (mostly tracking process group and controlling terminal -- heavily tied to shell login and process groups). In particular, sessions are a process concept, not a thread one. There is no guarantee th= at all httpds follow the model required for this to make sense. And if you have to fix httpds, you might as well just pass the information = to the worker in some side channel; either environment variables, or a pipe, or shared memory segment. I guess the target network daemon is sshd, which is single threaded, and for that it might work? But it doesn't really generalize, IMO. --=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-238319-227-aJ0FWA74BT>