Date: Thu, 21 Aug 2014 22:29:41 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 192900] New: There is no PAM-independent command to change the login class. Message-ID: <bug-192900-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192900 Bug ID: 192900 Summary: There is no PAM-independent command to change the login class. Product: Base System Version: 10.0-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: conf Assignee: freebsd-bugs@FreeBSD.org Reporter: ta0kira@gmail.com Created attachment 146133 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=146133&action=edit source for a program named "setloginclass" Problem: As far as I know, a login class, as a property of a process, is a new feature as of 9.0. With this new feature came the setloginclass(2) system call, which unfortunately is underutilized in the base system. In addition to having corresponding requirements in /etc/login.conf, login classes also allow the administrator to leverage rctl(8). Unfortunately, there seems to be no way to set the login class from a script or shell other than with su(1) (as far as I can tell). The problem with this is that su(1) uses PAM, which causes potential problems with pam_securetty.so, or other aspects of the PAM configuration. For example, suppose I'm logged in over ssh, and I want to restart cron with the login class "daemon": user@host$ sudo su -c daemon root -c 'service cron restart' Password: pam_securetty: pam_sm_acct_mgmt: Not on secure TTY su: Sorry Here, su's reliance on PAM causes a problem; however I'm not aware of another method of setting the login class and/or processing login.conf without su. The primary motivation for wanting a command-line tool that sets the login class and processes login.conf is so that I can modify the rc subsystem so that it sets a login class (and possibly a MAC label) for daemons. I've already done this on my system; however, it relies on a custom command-line program (see attached C file.) Solution: Provide a command-line program (such as the one attached) with the base system that processes login.conf without relying on PAM. Note that this requires the process to be run as root, which is not an issue in the contexts that it will be used in. Because su(1) is a general-purpose program for changing users, it must rely on PAM; therefore, it's not the appropriate tool if the administrator simply wants to change the login class. The program (whose source is attached) would be executed as follows: #restart cron under the login class "daemon"... root@host$ setloginclass daemon service cron restart #...as a normal user user@host$ sudo setloginclass daemon service cron restart #...also setting the MAC label root@host$ setloginclass -m daemon service cron restart #replace the current session with a new one that has login class "default" root@host$ exec setloginclass default -- 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-192900-8>