Created attachment 146133 [details]
source for a program named "setloginclass"
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'
pam_securetty: pam_sm_acct_mgmt: Not on secure TTY
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.)
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
Created attachment 146134 [details]
Makefile for setloginclass.c, also attached
See my comment and patch for bug 145009 (from today) for my usage of the program in the rc subsystem.
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.
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?
(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.
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.
(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.
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.
For bugs that match the following
- Status Is In progress
- Untouched since 2018-01-01.
- Affects Base System OR Documentation
Reset to open status.
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.