From owner-freebsd-bugs@FreeBSD.ORG Thu Aug 21 22:29:41 2014 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D73C15A8 for ; Thu, 21 Aug 2014 22:29:41 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE21C3EC3 for ; Thu, 21 Aug 2014 22:29:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7LMTfKp023722 for ; Thu, 21 Aug 2014 22:29:41 GMT (envelope-from bugzilla-noreply@freebsd.org) 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. Date: Thu, 21 Aug 2014 22:29:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ta0kira@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 22:29:42 -0000 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.