[Bug 192900] New: There is no PAM-independent command to change the login class.

[bugzilla-noreply at freebsd.org]

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 at FreeBSD.org
          Reporter: ta0kira at 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 at 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 at host$ setloginclass daemon service cron restart

#...as a normal user
user at host$ sudo setloginclass daemon service cron restart

#...also setting the MAC label
root at host$ setloginclass -m daemon service cron restart

#replace the current session with a new one that has login class "default"
root at host$ exec setloginclass default

-- 
You are receiving this mail because:
You are the assignee for the bug.