Bug 192900 - There is no PAM-independent command to change the login class.
Summary: There is no PAM-independent command to change the login class.
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 10.0-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: Dag-Erling Smørgrav
URL:
Keywords:
Depends on: 177698
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-21 22:29 UTC by Kevin Barry
Modified: 2018-05-28 19:50 UTC (History)
2 users (show)

See Also:


Attachments
source for a program named "setloginclass" (2.08 KB, text/plain)
2014-08-21 22:29 UTC, Kevin Barry
no flags Details
Makefile for setloginclass.c, also attached (393 bytes, text/plain)
2014-08-21 22:31 UTC, Kevin Barry
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Barry 2014-08-21 22:29:41 UTC
Created attachment 146133 [details]
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
Comment 1 Kevin Barry 2014-08-21 22:31:19 UTC
Created attachment 146134 [details]
Makefile for setloginclass.c, also attached
Comment 2 Kevin Barry 2014-08-21 23:02:45 UTC
See my comment and patch for bug 145009 (from today) for my usage of the program in the rc subsystem.
Comment 3 Kevin Barry 2014-08-21 23:05:50 UTC
This is also relates to bug 177698; however, the attached program could easily be modified so that it functions properly whether or not bug 177698 has been fixed.
Comment 4 Kevin Barry 2014-08-21 23:06:04 UTC
This is also relates to bug 177698; however, the attached program could easily be modified so that it functions properly whether or not bug 177698 has been fixed.
Comment 5 Dag-Erling Smørgrav freebsd_committer 2015-12-17 19:57:05 UTC
Looks interesting, but needs a lot of work.  Also, you didn't include a license.  Would the standard two-clause BSD license do, or do you prefer the three-clause (no-endorsement) version?
Comment 6 Kevin Barry 2017-04-23 20:51:02 UTC
(In reply to Dag-Erling Smørgrav from comment #5)
Sorry, I don't know how I missed the previous response. The two-clause license works.
Comment 7 Dag-Erling Smørgrav freebsd_committer 2017-04-25 10:51:43 UTC
The state of the code is still not even close to acceptable:

 - GNU indentation style
 - Mis-ordered #includes
 - Non-standard command-line parsing
 - Declarations mixed with code
 - No license in code
 - No man page

I suggest you look at some existing utilities and make at least a token effort to beat your code into shape.
Comment 8 Kevin Barry 2017-04-25 12:08:58 UTC
(In reply to Dag-Erling Smørgrav from comment #7)
Sorry, it sounded like you needed a license to use the code I posted as an example. I didn't expect it to actually be used as-is, and it's generally better to make an effort by writing the code to demo the feature than to just ask for it to be added. On the other hand, if no one else cares about this feature then it doesn't necessarily need to be added.
Comment 9 Dag-Erling Smørgrav freebsd_committer 2017-06-09 08:23:17 UTC
I understand.  I'm a little swamped at the moment, but if you prod me towards the end of June or middle of July, I may be able to work your patch into a committable shape, under 2BSD with both our names as authors.
Comment 10 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:50:38 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.