From gww@sac.sfbay.sun.com Tue Aug 12 17:22:22 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D0ML2H007085 for ; Tue, 12 Aug 2008 17:22:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7D0M2Z3000787; Wed, 13 Aug 2008 08:22:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5I00B07JP6VJ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Aug 2008 17:22:18 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I000UEJP68QC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Aug 2008 17:22:18 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7D0MHcs059861; Tue, 12 Aug 2008 17:22:17 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D0MFiS007080; Tue, 12 Aug 2008 17:22:15 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m7D0MFCS007076; Tue, 12 Aug 2008 17:22:15 -0700 (PDT) Date: Tue, 12 Aug 2008 17:22:15 -0700 (PDT) From: Gary Winiger Subject: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] To: psarc-ext@sun.com Cc: Aaron.Zang@sun.com, console-core@sun.com Message-id: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1788 I'm sponsoring this fast track for Aaron Zang and the Virtual Console team. This case proposes to eliminate the vtdaemon "rootunlock" property of PSARC/2006/591, Virtual Console. The Virtual Console project has not delivered into any version of OpenSolaris or Solaris so this case introduces no incompatibilities. This case proposes no change to the original approved Release Binding of patch/micro. The timer is set for 19 Aug, 2008. Gary.. ============================================================================= Background ========== PSARC/2006/591 proposed the virtual console feature for Solaris. The SMF service, svc:/system/vtdaemon:default, provides a secure switch function between different text virtual consoles. The vtdaemon service proposed a "rootunlock" property. When the value of "rootunlock" was "true", vtdaemon allowed unlocking text virtual consoles using the root user's password instead of the locking user's password. Update ====== The intention of the "rootunlock" property was to deal with a potential DoS (denial of service) attack, i.e., a user could log on to all available and switch away, thus all these text virtual consoles would be locked. The project team now considers the "rootunlock" property as unnecessary because: 1) Neither xlock nor xscreensaver have such an unlocking feature. 2) As all the virtual consoles are local, the access to virtual consoles is controlled by physical access. The "rootunlock" property is seen somewhat paranoid. It can also lead to incorrect attribution of actions to the locking user by another user. 3) A user with physical access to the console can cause other disruptive action. The project team proposes to eliminate the "rootunlock" property. From Alan.Coopersmith@sun.com Tue Aug 12 17:49:50 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D0nnrq007975 for ; Tue, 12 Aug 2008 17:49:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7D0nhlM010062; Wed, 13 Aug 2008 08:49:48 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5I00303KYXSH00@brm-avmta-1.central.sun.com>; Tue, 12 Aug 2008 18:49:45 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I00KH6KYWYS40@brm-avmta-1.central.sun.com>; Tue, 12 Aug 2008 18:49:45 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7D0niFs012583; Tue, 12 Aug 2008 17:49:44 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5I00F01KW4CB00@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM); Tue, 12 Aug 2008 17:49:44 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5I00B1FKYVXAG0@fe-sfbay-09.sun.com>; Tue, 12 Aug 2008 17:49:44 -0700 (PDT) Date: Tue, 12 Aug 2008 17:49:43 -0700 From: Alan Coopersmith Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> Sender: Alan.Coopersmith@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, Aaron.Zang@sun.com, console-core@sun.com Message-id: <48A22FA7.2090703@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1035 Gary Winiger wrote: > The vtdaemon service proposed a "rootunlock" property. When the value of > "rootunlock" was "true", vtdaemon allowed unlocking text virtual consoles > using the root user's password instead of the locking user's password. > > The project team now considers the "rootunlock" property as unnecessary > because: > > 1) Neither xlock nor xscreensaver have such an unlocking feature. I don't understand this claim - xlock, xscreensaver & CDE lockscreen all have a feature to allow unlocking the screen with the root password instead of the locking's users password, mostly because our customers demanded it be there. (Whether it's on or off by default differs by OS rev & program, but they all have it - see "-allowroot" in xlock(1), "Dtsession*keys" in dtsession(1), and the allowRoot xscreensaver resource defined in LSARC 2006/446 which we apparently forgot to document in the man page.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Aaron.Zang@sun.com Tue Aug 12 18:10:03 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D1A33H009172 for ; Tue, 12 Aug 2008 18:10:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7D1A2DQ010755; Tue, 12 Aug 2008 18:10:02 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5I00507LWNAK00@brm-avmta-1.central.sun.com>; Tue, 12 Aug 2008 19:09:59 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I00KOMLWMZ150@brm-avmta-1.central.sun.com>; Tue, 12 Aug 2008 19:09:59 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7D19wIv010168; Wed, 13 Aug 2008 01:09:58 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5I00901LU8XQ00@fe-emea-09.sun.com> (original mail from Aaron.Zang@Sun.COM); Wed, 13 Aug 2008 02:09:58 +0100 (BST) Received: from [129.158.217.200] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5I007K6LWIHM30@fe-emea-09.sun.com>; Wed, 13 Aug 2008 02:09:58 +0100 (BST) Date: Wed, 13 Aug 2008 09:08:23 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A22FA7.2090703@sun.com> Sender: Aaron.Zang@sun.com To: Alan Coopersmith Cc: Gary Winiger , psarc-ext@sun.com, console-core@sun.com Message-id: <48A23407.8080407@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 1507 Alan Coopersmith wrote: > Gary Winiger wrote: >> The vtdaemon service proposed a "rootunlock" property. When the value of >> "rootunlock" was "true", vtdaemon allowed unlocking text virtual consoles >> using the root user's password instead of the locking user's password. >> >> The project team now considers the "rootunlock" property as unnecessary >> because: >> >> 1) Neither xlock nor xscreensaver have such an unlocking feature. > > I don't understand this claim - xlock, xscreensaver & CDE lockscreen all have > a feature to allow unlocking the screen with the root password instead of the > locking's users password, mostly because our customers demanded it be there. > (Whether it's on or off by default differs by OS rev & program, but they > all have it - see "-allowroot" in xlock(1), "Dtsession*keys" in dtsession(1), > and the allowRoot xscreensaver resource defined in LSARC 2006/446 which > we apparently forgot to document in the man page.) > Yes, these locks all have code supporting root unlock, and there are macros functioning as switches to turn the feature on and off during compilation. Current Solaris releases always turn off the switches (without compiling this feature in). That what we really mean. And the root unlock feature of these locks was turned on in early Nevada build, but has been turned off nowadays, I think that is a sign of the trend -- no root unlock. -- aaron -- You know some birds are not meant to be caged, their feathers are just too bright. From gww@eng.sun.com Tue Aug 12 18:10:47 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D1AlcN009193 for ; Tue, 12 Aug 2008 18:10:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7D1AjwO018567; Wed, 13 Aug 2008 02:10:46 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5I00503LXWFQ00@brm-avmta-1.central.sun.com>; Tue, 12 Aug 2008 19:10:44 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I00KDSLXWYS50@brm-avmta-1.central.sun.com>; Tue, 12 Aug 2008 19:10:44 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7D1AgIP016468; Tue, 12 Aug 2008 18:10:42 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m7D17KKq008558; Tue, 12 Aug 2008 18:07:20 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m7D17KBJ008557; Tue, 12 Aug 2008 18:07:20 -0700 (PDT) Date: Tue, 12 Aug 2008 18:07:20 -0700 (PDT) From: Gary Winiger Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] To: gww@sac.sfbay.sun.com, Alan.Coopersmith@sun.com Cc: psarc-ext@sun.com, Aaron.Zang@sun.com, console-core@sun.com Message-id: <200808130107.m7D17KBJ008557@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 910 Alan, > > 1) Neither xlock nor xscreensaver have such an unlocking feature. > > I don't understand this claim - xlock, xscreensaver & CDE lockscreen all have > a feature to allow unlocking the screen with the root password instead of the > locking's users password, mostly because our customers demanded it be there. > (Whether it's on or off by default differs by OS rev & program, but they > all have it - see "-allowroot" in xlock(1), "Dtsession*keys" in dtsession(1), > and the allowRoot xscreensaver resource defined in LSARC 2006/446 which > we apparently forgot to document in the man page.) I asked both you an Mahmood in the last 6 months about xlock and xscreensaver. Perhaps I asked the wrong question. Perhaps I misunderstood the answer. Yes, by default dtsession (which is being left behind along with the rest of CDE ;-(, implements and enables root unlock by default. Gary.. From Aaron.Zang@sun.com Tue Aug 12 18:29:31 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D1TVlU009320 for ; Tue, 12 Aug 2008 18:29:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7D1TU8Z016369; Tue, 12 Aug 2008 18:29:31 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5I00J05MT7J600@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Aug 2008 18:29:31 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I00FG5MT44050@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Aug 2008 18:29:29 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7D1TSnY010401; Wed, 13 Aug 2008 01:29:28 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5I00G01MRIR900@fe-emea-09.sun.com> (original mail from Aaron.Zang@Sun.COM); Wed, 13 Aug 2008 02:29:28 +0100 (BST) Received: from [129.158.217.200] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5I007LXMSUHM30@fe-emea-09.sun.com>; Wed, 13 Aug 2008 02:29:28 +0100 (BST) Date: Wed, 13 Aug 2008 09:27:47 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <200808130107.m7D17KBJ008557@marduk.eng.sun.com> Sender: Aaron.Zang@sun.com To: Gary Winiger Cc: gww@sac.sfbay.sun.com, Alan.Coopersmith@sun.com, psarc-ext@sun.com, console-core@sun.com Message-id: <48A23893.8020303@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130107.m7D17KBJ008557@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 1247 Gary Winiger wrote: > Alan, > >>> 1) Neither xlock nor xscreensaver have such an unlocking feature. >> I don't understand this claim - xlock, xscreensaver & CDE lockscreen all have >> a feature to allow unlocking the screen with the root password instead of the >> locking's users password, mostly because our customers demanded it be there. >> (Whether it's on or off by default differs by OS rev & program, but they >> all have it - see "-allowroot" in xlock(1), "Dtsession*keys" in dtsession(1), >> and the allowRoot xscreensaver resource defined in LSARC 2006/446 which >> we apparently forgot to document in the man page.) > > I asked both you an Mahmood in the last 6 months about > xlock and xscreensaver. Perhaps I asked the wrong question. > Perhaps I misunderstood the answer. > > Yes, by default dtsession (which is being left behind along with > the rest of CDE ;-(, implements and enables root unlock by default. > Do we need to care about CDE lockscreen? I am running snv_93, even dtlogin has no CDE option in login session selection. OpenSolaris certainly does not use CDE. It may be because Sun is phasing out CDE. -- aaron -- You know some birds are not meant to be caged, their feathers are just too bright. From gww@eng.sun.com Tue Aug 12 18:33:17 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D1XHj0009364 for ; Tue, 12 Aug 2008 18:33:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7D1XDEp025624; Wed, 13 Aug 2008 02:33:16 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5I00C13MZFVS00@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Aug 2008 18:33:15 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I00A41MZDOW40@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Aug 2008 18:33:14 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7D1XC8Y026417; Tue, 12 Aug 2008 18:33:12 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m7D1TnDY008643; Tue, 12 Aug 2008 18:29:49 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m7D1TnpV008642; Tue, 12 Aug 2008 18:29:49 -0700 (PDT) Date: Tue, 12 Aug 2008 18:29:49 -0700 (PDT) From: Gary Winiger Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] To: gww@eng.sun.com, Aaron.Zang@sun.com Cc: gww@sac.sfbay.sun.com, Alan.Coopersmith@sun.com, psarc-ext@sun.com, console-core@sun.com Message-id: <200808130129.m7D1TnpV008642@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 476 ]> > Yes, by default dtsession (which is being left behind along with > > the rest of CDE ;-(, implements and enables root unlock by default. > > > > Do we need to care about CDE lockscreen? I am running snv_93, even dtlogin has > no CDE option in login session selection. OpenSolaris certainly does not use > CDE. It may be because Sun is phasing out CDE. IMO, no, that's what I meant by "which is being left behind along" ABICT, CDE will only be part of S10. Gary.. From Nicolas.Williams@sun.com Tue Aug 12 21:10:11 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D4ABeE013305 for ; Tue, 12 Aug 2008 21:10:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7D4A65c015272; Tue, 12 Aug 2008 21:10:09 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5I00J0RU8WLH00@brm-avmta-1.central.sun.com>; Tue, 12 Aug 2008 22:10:08 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I00KCXU8VYWE0@brm-avmta-1.central.sun.com>; Tue, 12 Aug 2008 22:10:07 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7D4A6FF016273; Tue, 12 Aug 2008 23:10:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7D4A6oP016272; Tue, 12 Aug 2008 23:10:06 -0500 (CDT) Date: Tue, 12 Aug 2008 23:10:05 -0500 From: Nicolas Williams Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> To: Gary Winiger Cc: psarc-ext@sun.com, Aaron.Zang@sun.com, console-core@sun.com Mail-followup-to: Gary Winiger , psarc-ext@sun.com, Aaron.Zang@sun.com, console-core@sun.com Message-id: <20080813041005.GF25547@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 188 On Tue, Aug 12, 2008 at 05:22:15PM -0700, Gary Winiger wrote: > The project team now considers the "rootunlock" property as unnecessary > because: Hmmm, and what if root has no password? From Aaron.Zang@sun.com Tue Aug 12 21:53:31 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D4rUde015307 for ; Tue, 12 Aug 2008 21:53:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7D4rNvN023547; Wed, 13 Aug 2008 12:53:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5I00K09W94Q000@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Aug 2008 21:53:28 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I00CU8W93UV90@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Aug 2008 21:53:28 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7D4rRQM013109; Wed, 13 Aug 2008 04:53:27 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5I00G01W4XZA00@fe-emea-09.sun.com> (original mail from Aaron.Zang@Sun.COM); Wed, 13 Aug 2008 05:53:27 +0100 (BST) Received: from [129.158.217.200] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5I00758W8ZHM40@fe-emea-09.sun.com>; Wed, 13 Aug 2008 05:53:27 +0100 (BST) Date: Wed, 13 Aug 2008 12:51:52 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <20080813041005.GF25547@Sun.COM> Sender: Aaron.Zang@sun.com To: Gary Winiger , psarc-ext@sun.com, Aaron.Zang@sun.com, console-core@sun.com Message-id: <48A26868.5030302@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <20080813041005.GF25547@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 571 Nicolas Williams wrote: > On Tue, Aug 12, 2008 at 05:22:15PM -0700, Gary Winiger wrote: >> The project team now considers the "rootunlock" property as unnecessary >> because: > > Hmmm, and what if root has no password? Here we are proposing to eliminate the "rootunlock" property. So if without the "rootunlock" property, user can not unlock the screen using root password. It does not matter if root has password or not. Or I didn't understand your question correctly. -- aaron -- You know some birds are not meant to be caged, their feathers are just too bright. From Nicolas.Williams@sun.com Tue Aug 12 22:06:36 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D56Z3g016133 for ; Tue, 12 Aug 2008 22:06:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7D56LL3027678; Wed, 13 Aug 2008 13:06:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5I00001WUXWM00@brm-avmta-1.central.sun.com>; Tue, 12 Aug 2008 23:06:33 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I00ME6WUWYR00@brm-avmta-1.central.sun.com>; Tue, 12 Aug 2008 23:06:32 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7D56VFO016295; Wed, 13 Aug 2008 00:06:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7D56V7F016294; Wed, 13 Aug 2008 00:06:31 -0500 (CDT) Date: Wed, 13 Aug 2008 00:06:31 -0500 From: Nicolas Williams Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A26868.5030302@Sun.COM> To: Aaron Zang Cc: Gary Winiger , psarc-ext@sun.com, console-core@sun.com Mail-followup-to: Aaron Zang , Gary Winiger , psarc-ext@sun.com, console-core@sun.com Message-id: <20080813050631.GH25547@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <20080813041005.GF25547@Sun.COM> <48A26868.5030302@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 664 On Wed, Aug 13, 2008 at 12:51:52PM +0800, Aaron Zang wrote: > Nicolas Williams wrote: > >On Tue, Aug 12, 2008 at 05:22:15PM -0700, Gary Winiger wrote: > >>The project team now considers the "rootunlock" property as unnecessary > >>because: > > > >Hmmm, and what if root has no password? > > Here we are proposing to eliminate the "rootunlock" property. So if without > the "rootunlock" property, user can not unlock the screen using root > password. > It does not matter if root has password or not. > > Or I didn't understand your question correctly. What I meant is that the prospect of root not having a password too makes rootunlock pointless :) Nico -- From Aaron.Zang@sun.com Tue Aug 12 22:09:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7D59sVH016272 for ; Tue, 12 Aug 2008 22:09:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7D59pqT027713; Wed, 13 Aug 2008 06:09:53 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5I00005X0GQS00@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Aug 2008 22:09:52 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I00JXEX0FWO20@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Aug 2008 22:09:52 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7D59pIZ019578; Wed, 13 Aug 2008 05:09:51 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5I00101WUIC500@fe-emea-09.sun.com> (original mail from Aaron.Zang@Sun.COM); Wed, 13 Aug 2008 06:09:50 +0100 (BST) Received: from [129.158.217.200] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5I0077HX0BHM40@fe-emea-09.sun.com>; Wed, 13 Aug 2008 06:09:50 +0100 (BST) Date: Wed, 13 Aug 2008 13:08:16 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <20080813050631.GH25547@Sun.COM> Sender: Aaron.Zang@sun.com To: Aaron Zang , Gary Winiger , psarc-ext@sun.com, console-core@sun.com Message-id: <48A26C40.9080305@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <20080813041005.GF25547@Sun.COM> <48A26868.5030302@Sun.COM> <20080813050631.GH25547@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 870 Nicolas Williams wrote: > On Wed, Aug 13, 2008 at 12:51:52PM +0800, Aaron Zang wrote: >> Nicolas Williams wrote: >>> On Tue, Aug 12, 2008 at 05:22:15PM -0700, Gary Winiger wrote: >>>> The project team now considers the "rootunlock" property as unnecessary >>>> because: >>> Hmmm, and what if root has no password? >> Here we are proposing to eliminate the "rootunlock" property. So if without >> the "rootunlock" property, user can not unlock the screen using root >> password. >> It does not matter if root has password or not. >> >> Or I didn't understand your question correctly. > > What I meant is that the prospect of root not having a password too > makes rootunlock pointless :) Ahhhh, it should count for one additional reason that we are doing this. Thanks. -- aaron -- You know some birds are not meant to be caged, their feathers are just too bright. From Alan.Coopersmith@sun.com Wed Aug 13 07:43:20 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7DEhJMt029513 for ; Wed, 13 Aug 2008 07:43:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7DEhFD4011825; Wed, 13 Aug 2008 22:43:18 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5J00K03NK42M00@brm-avmta-1.central.sun.com>; Wed, 13 Aug 2008 08:43:16 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5J007XRNK3AAA0@brm-avmta-1.central.sun.com>; Wed, 13 Aug 2008 08:43:15 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7DEhFW0008620; Wed, 13 Aug 2008 07:43:15 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5J00H01N9NIX00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM); Wed, 13 Aug 2008 07:43:15 -0700 (PDT) Received: from [10.6.102.118] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5J00760NK22WD0@fe-sfbay-10.sun.com>; Wed, 13 Aug 2008 07:43:15 -0700 (PDT) Date: Wed, 13 Aug 2008 07:43:14 -0700 From: Alan Coopersmith Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A23407.8080407@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Aaron Zang Cc: Gary Winiger , psarc-ext@sun.com, console-core@sun.com Message-id: <48A2F302.2040701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1662 Aaron Zang wrote: > Alan Coopersmith wrote: >> Gary Winiger wrote: >>> The vtdaemon service proposed a "rootunlock" property. When the >>> value of >>> "rootunlock" was "true", vtdaemon allowed unlocking text virtual >>> consoles >>> using the root user's password instead of the locking user's password. >>> >>> The project team now considers the "rootunlock" property as unnecessary >>> because: >>> >>> 1) Neither xlock nor xscreensaver have such an unlocking feature. >> >> I don't understand this claim - xlock, xscreensaver & CDE lockscreen >> all have >> a feature to allow unlocking the screen with the root password instead >> of the >> locking's users password, mostly because our customers demanded it be >> there. >> (Whether it's on or off by default differs by OS rev & program, but they >> all have it - see "-allowroot" in xlock(1), "Dtsession*keys" in >> dtsession(1), >> and the allowRoot xscreensaver resource defined in LSARC 2006/446 which >> we apparently forgot to document in the man page.) >> > > Yes, these locks all have code supporting root unlock, and there are macros > functioning as switches to turn the feature on and off during compilation. > Current Solaris releases always turn off the switches (without compiling > this > feature in). That what we really mean. That is still wrong - they are all still built with the feature present. In current Nevada builds the feature is not enabled by default, but can be turned on at runtime, without a recompile, by just setting the flag/properties mentioned. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Aaron.Zang@sun.com Wed Aug 13 17:45:29 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7E0jSBq025454 for ; Wed, 13 Aug 2008 17:45:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7E0jNlV005923; Thu, 14 Aug 2008 01:45:27 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5K00503FFQJC00@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Aug 2008 17:45:26 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5K004HNFFPDE20@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Aug 2008 17:45:25 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7E0jO93027448; Thu, 14 Aug 2008 00:45:24 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5K00K01FD8J900@fe-emea-10.sun.com> (original mail from Aaron.Zang@Sun.COM); Thu, 14 Aug 2008 01:45:24 +0100 (BST) Received: from [129.158.217.200] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5K00AFIFFHKM00@fe-emea-10.sun.com>; Thu, 14 Aug 2008 01:45:24 +0100 (BST) Date: Thu, 14 Aug 2008 08:43:45 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A2F302.2040701@sun.com> Sender: Aaron.Zang@sun.com To: Alan Coopersmith Cc: Gary Winiger , psarc-ext@sun.com, console-core@sun.com Message-id: <48A37FC1.4000109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 2192 Alan Coopersmith wrote: > Aaron Zang wrote: >> Alan Coopersmith wrote: >>> Gary Winiger wrote: >>>> The vtdaemon service proposed a "rootunlock" property. When the >>>> value of >>>> "rootunlock" was "true", vtdaemon allowed unlocking text virtual >>>> consoles >>>> using the root user's password instead of the locking user's password. >>>> >>>> The project team now considers the "rootunlock" property as unnecessary >>>> because: >>>> >>>> 1) Neither xlock nor xscreensaver have such an unlocking feature. >>> I don't understand this claim - xlock, xscreensaver & CDE lockscreen >>> all have >>> a feature to allow unlocking the screen with the root password instead >>> of the >>> locking's users password, mostly because our customers demanded it be >>> there. >>> (Whether it's on or off by default differs by OS rev & program, but they >>> all have it - see "-allowroot" in xlock(1), "Dtsession*keys" in >>> dtsession(1), >>> and the allowRoot xscreensaver resource defined in LSARC 2006/446 which >>> we apparently forgot to document in the man page.) >>> >> Yes, these locks all have code supporting root unlock, and there are macros >> functioning as switches to turn the feature on and off during compilation. >> Current Solaris releases always turn off the switches (without compiling >> this >> feature in). That what we really mean. > > That is still wrong - they are all still built with the feature present. > In current Nevada builds the feature is not enabled by default, but > can be turned on at runtime, without a recompile, by just setting > the flag/properties mentioned. > OK, I see. I tried xlock -allowroot on my system, it did work. And I found a "AllowRoot" entry in ~/.xscreensaver with "False" as default. It seems that we should refine our claim like this: "Neither xlock nor xscreensaver support such an unlocking feature by default" Is it correct? Anyway, I still believe that the trend is to not using rootunlock. I still remember that around Nevada build 30, xscreensaver supported rootunlock by default, and now it is not the default behavior. -- aaron -- You know some birds are not meant to be caged, their feathers are just too bright. From Michael.Schuster@sun.com Thu Aug 14 08:12:09 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7EFC83W018784 for ; Thu, 14 Aug 2008 08:12:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7EFC0Rx049224; Thu, 14 Aug 2008 09:12:08 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5L00H03JK7KH00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Aug 2008 08:12:07 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00G7FJK6R610@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Aug 2008 08:12:07 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7EFC62S011233; Thu, 14 Aug 2008 08:12:06 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5L00E01IWR1H00@fe-sfbay-10.sun.com> (original mail from Michael.Schuster@Sun.COM); Thu, 14 Aug 2008 08:12:06 -0700 (PDT) Received: from [129.146.106.37] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5L009FSJJ82T10@fe-sfbay-10.sun.com>; Thu, 14 Aug 2008 08:11:33 -0700 (PDT) Date: Thu, 14 Aug 2008 08:11:32 -0700 From: Michael Schuster Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A37FC1.4000109@Sun.COM> Sender: Michael.Schuster@sun.com To: Aaron Zang Cc: psarc-ext@sun.com, console-core@sun.com Message-id: <48A44B24.2090208@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 2374 Aaron Zang wrote: > Alan Coopersmith wrote: >> Aaron Zang wrote: >>> Alan Coopersmith wrote: >>>> Gary Winiger wrote: >>>>> The vtdaemon service proposed a "rootunlock" property. When the >>>>> value of >>>>> "rootunlock" was "true", vtdaemon allowed unlocking text virtual >>>>> consoles >>>>> using the root user's password instead of the locking user's password. >>>>> >>>>> The project team now considers the "rootunlock" property as >>>>> unnecessary >>>>> because: >>>>> >>>>> 1) Neither xlock nor xscreensaver have such an unlocking feature. >>>> I don't understand this claim - xlock, xscreensaver & CDE lockscreen >>>> all have >>>> a feature to allow unlocking the screen with the root password instead >>>> of the >>>> locking's users password, mostly because our customers demanded it be >>>> there. >>>> (Whether it's on or off by default differs by OS rev & program, but >>>> they >>>> all have it - see "-allowroot" in xlock(1), "Dtsession*keys" in >>>> dtsession(1), >>>> and the allowRoot xscreensaver resource defined in LSARC 2006/446 >>>> which >>>> we apparently forgot to document in the man page.) >>>> >>> Yes, these locks all have code supporting root unlock, and there are >>> macros >>> functioning as switches to turn the feature on and off during >>> compilation. >>> Current Solaris releases always turn off the switches (without compiling >>> this >>> feature in). That what we really mean. >> >> That is still wrong - they are all still built with the feature present. >> In current Nevada builds the feature is not enabled by default, but >> can be turned on at runtime, without a recompile, by just setting >> the flag/properties mentioned. >> > > OK, I see. I tried xlock -allowroot on my system, it did work. > And I found a "AllowRoot" entry in ~/.xscreensaver with "False" as default. > > It seems that we should refine our claim like this: > "Neither xlock nor xscreensaver support such an unlocking feature by > default" > Is it correct? > > Anyway, I still believe that the trend is to not using rootunlock. I still > remember that around Nevada build 30, xscreensaver supported rootunlock by > default, and now it is not the default behavior. IMO it would make sense to retain the capability, but turn it off by default. Michael -- Michael Schuster http://blogs.sun.com/recursion Recursion, n.: see 'Recursion' From Aaron.Zang@sun.com Thu Aug 14 17:19:37 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7F0JbeG016259 for ; Thu, 14 Aug 2008 17:19:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7F0JZdN027834; Thu, 14 Aug 2008 17:19:36 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5M0050H8WN8S00@brm-avmta-1.central.sun.com>; Thu, 14 Aug 2008 18:19:35 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5M00JCU8WMFX90@brm-avmta-1.central.sun.com>; Thu, 14 Aug 2008 18:19:35 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7F0JXGW011146; Fri, 15 Aug 2008 00:19:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5M008018T2G700@fe-emea-09.sun.com> (original mail from Aaron.Zang@Sun.COM); Fri, 15 Aug 2008 01:19:33 +0100 (BST) Received: from [129.158.217.200] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5M00I9R8WH3930@fe-emea-09.sun.com>; Fri, 15 Aug 2008 01:19:33 +0100 (BST) Date: Fri, 15 Aug 2008 08:17:56 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A44B24.2090208@sun.com> Sender: Aaron.Zang@sun.com To: Michael Schuster Cc: psarc-ext@sun.com, console-core@sun.com, Gary Winiger Message-id: <48A4CB34.3090207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 1334 Michael Schuster wrote: >> Anyway, I still believe that the trend is to not using rootunlock. I >> still >> remember that around Nevada build 30, xscreensaver supported >> rootunlock by >> default, and now it is not the default behavior. > > IMO it would make sense to retain the capability, but turn it off by > default. There are actually other reasons that we want to get rid of root unlock, as stated as reason #2 and #3. The Xsession lock is just one aspect. A more serious problem that can be resulted from root unlocking is that root user can unlock a normal user's console and get this normal user's attribute without any record. Of course, root user can always do this by "su", but the "su" could be audited if audit is enabled. Whereas in our case, the right way to do audit is to set up audit context from the ucred of the process running on the virtual console being unlocked. If we allow root unlock, and we want to record this behavior, we have to make up a fake root audit context, and this is really a very bad thing to do and is not a correct behavior as allowed by audit. The above may explain "It can also lead to incorrect attribution of actions to the locking user by another user." as stated in reason #2. -- aaron -- You know some birds are not meant to be caged, their feathers are just too bright. From kmcdonald@egenera.com Fri Aug 15 08:47:28 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7FFlR5H007045 for ; Fri, 15 Aug 2008 08:47:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7FFl8p3021149; Fri, 15 Aug 2008 16:47:23 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5N0052JFUYYY00@brm-avmta-1.central.sun.com>; Fri, 15 Aug 2008 09:47:22 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00L8HFUN3L70@brm-avmta-1.central.sun.com>; Fri, 15 Aug 2008 09:47:11 -0600 (MDT) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7FFcFCZ016282; Fri, 15 Aug 2008 15:47:10 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay24i.sun.com with ESMTP id BT-MMP-1823055; Fri, 15 Aug 2008 15:47:06 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-54056621; Fri, 15 Aug 2008 15:47:06 +0000 (Z) Received: from webaccess.egenera.com ([63.139.209.15] [63.139.209.15]) by relay22i.sun.com with ESMTP id BT-MMP-7222287; Fri, 15 Aug 2008 15:47:05 +0000 (Z) Received: from [172.23.2.128] ([172.23.2.128]) by webaccess.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 11:47:04 -0400 Date: Fri, 15 Aug 2008 11:47:05 -0400 From: Kyle McDonald Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A4CB34.3090207@Sun.COM> To: Aaron Zang Cc: Michael Schuster , psarc-ext@sun.com, console-core@sun.com, Gary Winiger Message-id: <48A5A4F9.7020307@Egenera.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 15 Aug 2008 15:47:04.0597 (UTC) FILETIME=[2A556450:01C8FEEE] Status: RO Content-Length: 1983 Aaron Zang wrote: > Michael Schuster wrote: > > >>> Anyway, I still believe that the trend is to not using rootunlock. I >>> still >>> remember that around Nevada build 30, xscreensaver supported >>> rootunlock by >>> default, and now it is not the default behavior. >>> >> IMO it would make sense to retain the capability, but turn it off by >> default. >> > > There are actually other reasons that we want to get rid of root unlock, > as stated as reason #2 and #3. The Xsession lock is just one aspect. > > A more serious problem that can be resulted from root unlocking is that > root user can unlock a normal user's console and get this normal user's > attribute without any record. Of course, root user can always do this by "su", > but the "su" could be audited if audit is enabled. > Whereas in our case, the right way to do audit is to set up audit context > from the ucred of the process running on the virtual console being unlocked. > If we allow root unlock, and we want to record this behavior, we have to > make up a fake root audit context, and this is really a very bad thing to do > and is not a correct behavior as allowed by audit. > The above may explain "It can also lead to incorrect attribution of actions > to the locking user by another user." as stated in reason #2. > > When Running large computer labs at universities, this root-unlock feature has been a godsend for when users lock their terminals and leave the lab, and there are no other workstations available for new users. What if the only thing the root password could do was to unlock *and* logout the session on that console. In other words they wouldn't be allowed access to the running processes, they would just be returned to the login prompt. What I never liked was that it meant we needed to give the lab proctors the root password to the lab workstations. Maybe something could be done with with roles, profles, etc. for this? - Kyle > -- aaron > > > From Aaron.Zang@Sun.COM Fri Aug 15 23:57:53 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7G6vqTH020192 for ; Fri, 15 Aug 2008 23:57:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7G6voYk013103; Sat, 16 Aug 2008 14:57:51 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5O00503M0DCW00@brm-avmta-1.central.sun.com>; Sat, 16 Aug 2008 00:57:49 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5O00JLMM0BSLA0@brm-avmta-1.central.sun.com>; Sat, 16 Aug 2008 00:57:49 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7G6vlqB025788; Sat, 16 Aug 2008 06:57:47 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5O00K01LKJCZ00@mail-apac.sun.com> (original mail from Aaron.Zang@Sun.COM); Sat, 16 Aug 2008 14:57:47 +0800 (SGT) Received: from [192.168.1.33] ([123.118.18.53]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5O004AEM01PGI3@mail-apac.sun.com>; Sat, 16 Aug 2008 14:57:46 +0800 (SGT) Date: Sat, 16 Aug 2008 14:57:25 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A5A4F9.7020307@Egenera.COM> Sender: Aaron.Zang@Sun.COM To: Kyle McDonald Cc: Michael Schuster , psarc-ext@Sun.COM, console-core@Sun.COM, Gary Winiger Message-id: <48A67A55.2060904@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> <48A5A4F9.7020307@Egenera.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 2861 Kyle McDonald wrote: > Aaron Zang wrote: >> >> There are actually other reasons that we want to get rid of root unlock, >> as stated as reason #2 and #3. The Xsession lock is just one aspect. >> >> A more serious problem that can be resulted from root unlocking is that >> root user can unlock a normal user's console and get this normal user's >> attribute without any record. Of course, root user can always do this >> by "su", >> but the "su" could be audited if audit is enabled. >> Whereas in our case, the right way to do audit is to set up audit >> context >> from the ucred of the process running on the virtual console being >> unlocked. >> If we allow root unlock, and we want to record this behavior, we have to >> make up a fake root audit context, and this is really a very bad >> thing to do >> and is not a correct behavior as allowed by audit. >> The above may explain "It can also lead to incorrect attribution of >> actions >> to the locking user by another user." as stated in reason #2. >> >> > When Running large computer labs at universities, this root-unlock > feature has been a godsend for when users lock their terminals and > leave the lab, and there are no other workstations available for new > users. > If virtual console is enabled, there will be multiple virtual consoles providing both console login sessions and graphic sessions. Whoever locked *ALL* these sessions should be treated as malicious user and should be punished somehow. > What if the only thing the root password could do was to unlock *and* > logout the session on that console. In other words they wouldn't be > allowed access to the running processes, they would just be returned > to the login prompt. > vtdaemon does console locking/unlocking on behalf of the console session being locked/unlocked. If we allow root to unlock the session, no matter it has restricted accessibility or not, we should audit this unlocking event. This will eventually result in faking a root audit context, and that is *not allowed* by SUN audit policy. > What I never liked was that it meant we needed to give the lab > proctors the root password to the lab workstations. > Maybe something could be done with with roles, profles, etc. for this? The project team believes that the accessibility to the local physical consoles should be managed properly. If a person is ever allowed to access the local console, he/she should be trusted to behave properly. Virtual consoles could solve by some degree the situation that a person *accidentally* locked several of the available virtual consoles, the system administrator could login via one of the rest of the available consoles and deal with the mess. But if all the available virtual consoles are locked out, what should be blamed is the management of physical access to the local consoles. -- aaron From jgh@wizmail.org Sat Aug 16 07:13:07 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7GED62g028600 for ; Sat, 16 Aug 2008 07:13:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7GED3IO012160 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 16 Aug 2008 22:13:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5P00G0165S4200@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Sat, 16 Aug 2008 07:13:04 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5P0020G65R0480@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Sat, 16 Aug 2008 07:13:03 -0700 (PDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7GE559H000159 for ; Sat, 16 Aug 2008 14:13:03 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay21i.sun.com with ESMTP id BT-MMP-1866212 for psarc-ext@Sun.COM; Sat, 16 Aug 2008 14:13:02 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-56396908 for psarc-ext@Sun.COM; Sat, 16 Aug 2008 14:13:02 +0000 (Z) Received: from wizmail.org ([217.146.107.12] [217.146.107.12]) by relay21i.sun.com with ESMTP id BT-MMP-10320310 for psarc-ext@Sun.COM; Sat, 16 Aug 2008 14:13:02 +0000 (Z) Received: from ebony.jgh.adsl.wizards.co.uk ([217.146.123.59]) (from_AS 16353) by wizmail.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.67) id 1KUMWb-00012i-49 (return-path ); Sat, 16 Aug 2008 14:13:01 +0000 Date: Sat, 16 Aug 2008 15:12:50 +0100 From: Jeremy Harris Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A67A55.2060904@Sun.COM> To: Aaron Zang Cc: Kyle McDonald , psarc-ext@sun.com, console-core@sun.com, Gary Winiger , Michael Schuster Message-id: <48A6E062.7050500@wizmail.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.056sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> <48A5A4F9.7020307@Egenera.COM> <48A67A55.2060904@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080723 Fedora/2.0.0.16-1.fc9 Thunderbird/2.0.0.16 Mnenhy/0.7.5.0 Status: RO Content-Length: 676 Aaron Zang wrote: > If a person is ever allowed to access the local console, he/she should > be trusted to behave properly. > Virtual consoles could solve by some degree the situation that a person > *accidentally* locked several > of the available virtual consoles, the system administrator could login > via one of the rest of the available > consoles and deal with the mess. But if all the available virtual > consoles are locked out, what should be > blamed is the management of physical access to the local consoles. All very reasonable for a server-class system. Totally useless for a single-monitor, single keyboard system in a student environment. - Jeremy From gdamore@sun.com Sat Aug 16 08:41:44 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7GFfhfM029334 for ; Sat, 16 Aug 2008 08:41:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7GFff19004344; Sat, 16 Aug 2008 23:41:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5P00L09A9GGB00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 16 Aug 2008 08:41:40 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5P008K3A9C5670@nwk-avmta-1.sfbay.Sun.COM>; Sat, 16 Aug 2008 08:41:40 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7GFfaMa024684; Sat, 16 Aug 2008 08:41:36 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5P00J01A2S1B00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Sat, 16 Aug 2008 08:41:36 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5P00CA2A9BYOC0@fe-sfbay-10.sun.com>; Sat, 16 Aug 2008 08:41:36 -0700 (PDT) Date: Sat, 16 Aug 2008 08:35:38 -0700 From: "Garrett D'Amore" Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A67A55.2060904@Sun.COM> Sender: Garrett.Damore@sun.com To: Aaron Zang Cc: Kyle McDonald , Michael Schuster , psarc-ext@sun.com, console-core@sun.com, Gary Winiger Message-id: <48A6F3CA.4030307@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> <48A5A4F9.7020307@Egenera.COM> <48A67A55.2060904@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3431 A possible workaround/comprromise: What if there was one extra VT, that was only available to administrators? Then a root user could always login, and if necessary kill off the sessions holding the other VTs. This wouldn't break auditing, and it wouldn't require the console keyboard and monitor to be secured at all costs. (The usual concerns about BIOS access other local access considerations still apply, of course.) -- Garrett Aaron Zang wrote: > Kyle McDonald wrote: >> Aaron Zang wrote: >>> >>> There are actually other reasons that we want to get rid of root >>> unlock, >>> as stated as reason #2 and #3. The Xsession lock is just one aspect. >>> >>> A more serious problem that can be resulted from root unlocking is that >>> root user can unlock a normal user's console and get this normal user's >>> attribute without any record. Of course, root user can always do >>> this by "su", >>> but the "su" could be audited if audit is enabled. >>> Whereas in our case, the right way to do audit is to set up audit >>> context >>> from the ucred of the process running on the virtual console being >>> unlocked. >>> If we allow root unlock, and we want to record this behavior, we >>> have to >>> make up a fake root audit context, and this is really a very bad >>> thing to do >>> and is not a correct behavior as allowed by audit. >>> The above may explain "It can also lead to incorrect attribution of >>> actions >>> to the locking user by another user." as stated in reason #2. >>> >>> >> When Running large computer labs at universities, this root-unlock >> feature has been a godsend for when users lock their terminals and >> leave the lab, and there are no other workstations available for new >> users. >> > If virtual console is enabled, there will be multiple virtual consoles > providing both > console login sessions and graphic sessions. > Whoever locked *ALL* these sessions should be treated as malicious > user and > should be punished somehow. > >> What if the only thing the root password could do was to unlock *and* >> logout the session on that console. In other words they wouldn't be >> allowed access to the running processes, they would just be returned >> to the login prompt. >> > vtdaemon does console locking/unlocking on behalf of the console > session being locked/unlocked. > If we allow root to unlock the session, no matter it has restricted > accessibility or not, we should audit > this unlocking event. This will eventually result in faking a root > audit context, and that is *not allowed* > by SUN audit policy. >> What I never liked was that it meant we needed to give the lab >> proctors the root password to the lab workstations. >> Maybe something could be done with with roles, profles, etc. for this? > The project team believes that the accessibility to the local physical > consoles should be managed properly. > If a person is ever allowed to access the local console, he/she should > be trusted to behave properly. > Virtual consoles could solve by some degree the situation that a > person *accidentally* locked several > of the available virtual consoles, the system administrator could > login via one of the rest of the available > consoles and deal with the mess. But if all the available virtual > consoles are locked out, what should be > blamed is the management of physical access to the local consoles. > > -- aaron From Aaron.Zang@Sun.COM Sat Aug 16 20:33:49 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7H3XmvK011591 for ; Sat, 16 Aug 2008 20:33:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7H3XlJp008402; Sun, 17 Aug 2008 04:33:47 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5Q00A0178A5D00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 16 Aug 2008 20:33:46 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Q009LM783WX00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 16 Aug 2008 20:33:46 -0700 (PDT) Received: from fe-apac-01.sun.com (fe-apac-01.sun.com [192.18.19.172] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7H3XcX6007073; Sun, 17 Aug 2008 03:33:38 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5Q0060176HVY00@mail-apac.sun.com> (original mail from Aaron.Zang@Sun.COM); Sun, 17 Aug 2008 11:33:38 +0800 (SGT) Received: from [192.168.1.33] ([123.118.8.88]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5Q005SJ77USYQ1@mail-apac.sun.com>; Sun, 17 Aug 2008 11:33:38 +0800 (SGT) Date: Sun, 17 Aug 2008 11:33:22 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A6E062.7050500@wizmail.org> Sender: Aaron.Zang@Sun.COM To: Jeremy Harris Cc: Kyle McDonald , psarc-ext@Sun.COM, console-core@Sun.COM, Gary Winiger , Michael Schuster Message-id: <48A79C02.7070207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> <48A5A4F9.7020307@Egenera.COM> <48A67A55.2060904@Sun.COM> <48A6E062.7050500@wizmail.org> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 1052 Jeremy Harris wrote: > Aaron Zang wrote: >> If a person is ever allowed to access the local console, he/she >> should be trusted to behave properly. >> Virtual consoles could solve by some degree the situation that a >> person *accidentally* locked several >> of the available virtual consoles, the system administrator could >> login via one of the rest of the available >> consoles and deal with the mess. But if all the available virtual >> consoles are locked out, what should be >> blamed is the management of physical access to the local consoles. > > All very reasonable for a server-class system. Totally useless for a > single-monitor, single keyboard system in a student environment. > While in a student environment, it's almost safe to say nothing important (business/money related) service is running on that system, so the system admin could even hammer the system to get it back. The locked system situation is not first introduced by virtual console, and it's by the nature of locking screen on a workstation. -- aaron From Aaron.Zang@sun.com Sat Aug 16 20:41:36 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7H3fZXB011616 for ; Sat, 16 Aug 2008 20:41:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7H3fXGr062085; Sat, 16 Aug 2008 21:41:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5Q00A2T7LAMV00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 16 Aug 2008 20:41:34 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Q009RT7ITWX10@nwk-avmta-1.sfbay.Sun.COM>; Sat, 16 Aug 2008 20:40:05 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7H3e4ko007160; Sun, 17 Aug 2008 03:40:04 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5Q003017AVAA00@mail-apac.sun.com> (original mail from Aaron.Zang@Sun.COM); Sun, 17 Aug 2008 11:40:04 +0800 (SGT) Received: from [192.168.1.33] ([123.118.8.88]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5Q00MGP7IOLRTV@mail-apac.sun.com>; Sun, 17 Aug 2008 11:40:04 +0800 (SGT) Date: Sun, 17 Aug 2008 11:39:52 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A79C02.7070207@Sun.COM> Sender: Aaron.Zang@sun.com To: Jeremy Harris Cc: Kyle McDonald , psarc-ext@sun.com, console-core@sun.com, Gary Winiger , Michael Schuster Message-id: <48A79D88.8010600@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> <48A5A4F9.7020307@Egenera.COM> <48A67A55.2060904@Sun.COM> <48A6E062.7050500@wizmail.org> <48A79C02.7070207@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 1277 Aaron Zang wrote: > Jeremy Harris wrote: >> Aaron Zang wrote: >>> If a person is ever allowed to access the local console, he/she >>> should be trusted to behave properly. >>> Virtual consoles could solve by some degree the situation that a >>> person *accidentally* locked several >>> of the available virtual consoles, the system administrator could >>> login via one of the rest of the available >>> consoles and deal with the mess. But if all the available virtual >>> consoles are locked out, what should be >>> blamed is the management of physical access to the local consoles. >> >> All very reasonable for a server-class system. Totally useless for a >> single-monitor, single keyboard system in a student environment. >> > > While in a student environment, it's almost safe to say nothing > important (business/money related) > service is running on that system, so the system admin could even > hammer the system to get it back. > > The locked system situation is not first introduced by virtual > console, and it's by the nature of locking > screen on a workstation. > And in a student environment, I think is OK to disable the console locking to get rid of all the mess. We provide the option to disable the locking feature. -- aaron > -- aaron > From Aaron.Zang@sun.com Sat Aug 16 21:01:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7H41hBN012047 for ; Sat, 16 Aug 2008 21:01:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7H41fAX014184; Sun, 17 Aug 2008 05:01:42 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5Q00A018ITOT00@nwk-avmta-2.sfbay.sun.com>; Sat, 16 Aug 2008 21:01:41 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Q0046G8ISZXF0@nwk-avmta-2.sfbay.sun.com>; Sat, 16 Aug 2008 21:01:41 -0700 (PDT) Received: from fe-apac-02.sun.com (fe-apac-02.sun.com [192.18.19.173] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7H41edp000821; Sun, 17 Aug 2008 04:01:40 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5Q00I017WH1700@mail-apac.sun.com> (original mail from Aaron.Zang@Sun.COM); Sun, 17 Aug 2008 12:01:40 +0800 (SGT) Received: from [192.168.1.33] ([123.118.8.88]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5Q003V58INTC33@mail-apac.sun.com>; Sun, 17 Aug 2008 12:01:39 +0800 (SGT) Date: Sun, 17 Aug 2008 12:01:27 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A6F3CA.4030307@sun.com> Sender: Aaron.Zang@sun.com To: "Garrett D'Amore" Cc: Kyle McDonald , Michael Schuster , psarc-ext@sun.com, console-core@sun.com, Gary Winiger Message-id: <48A7A297.9010900@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> <48A5A4F9.7020307@Egenera.COM> <48A67A55.2060904@Sun.COM> <48A6F3CA.4030307@sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 4553 Hi Garrett, Thanks for your suggestion. Actually we've thought about this idea during the very beginning of project design. The thing is which virtual console should be reserved for root use only. The system console (/dev/console) is not the possible choice, since it would change the behavior of the system console, it might be seen as a regression. And for the other virtual consoles, we actually allow to dynamic reconfig the available virtual console number. Even if the second virtual console /dev/vt/2 is chosen to only allow root login, there might be chances that the user re-configure it away. Of course a possible solution is to hard reserve 2 virtual consoles, but user might only want only one console session and only one graphic session. Anyway, people can always disable the console locking feature of virtual console by setting the "secure" option of vtdaemon service to "false", if the chances that mis-behaved users messing up the consoles are very high. -- aaron Garrett D'Amore wrote: > A possible workaround/comprromise: > > What if there was one extra VT, that was only available to > administrators? Then a root user could always login, and if necessary > kill off the sessions holding the other VTs. This wouldn't break > auditing, and it wouldn't require the console keyboard and monitor to > be secured at all costs. (The usual concerns about BIOS access other > local access considerations still apply, of course.) > > -- Garrett > > > Aaron Zang wrote: >> Kyle McDonald wrote: >>> Aaron Zang wrote: >>>> >>>> There are actually other reasons that we want to get rid of root >>>> unlock, >>>> as stated as reason #2 and #3. The Xsession lock is just one aspect. >>>> >>>> A more serious problem that can be resulted from root unlocking is >>>> that >>>> root user can unlock a normal user's console and get this normal >>>> user's >>>> attribute without any record. Of course, root user can always do >>>> this by "su", >>>> but the "su" could be audited if audit is enabled. >>>> Whereas in our case, the right way to do audit is to set up audit >>>> context >>>> from the ucred of the process running on the virtual console being >>>> unlocked. >>>> If we allow root unlock, and we want to record this behavior, we >>>> have to >>>> make up a fake root audit context, and this is really a very bad >>>> thing to do >>>> and is not a correct behavior as allowed by audit. >>>> The above may explain "It can also lead to incorrect attribution of >>>> actions >>>> to the locking user by another user." as stated in reason #2. >>>> >>>> >>> When Running large computer labs at universities, this root-unlock >>> feature has been a godsend for when users lock their terminals and >>> leave the lab, and there are no other workstations available for new >>> users. >>> >> If virtual console is enabled, there will be multiple virtual >> consoles providing both >> console login sessions and graphic sessions. >> Whoever locked *ALL* these sessions should be treated as malicious >> user and >> should be punished somehow. >> >>> What if the only thing the root password could do was to unlock >>> *and* logout the session on that console. In other words they >>> wouldn't be allowed access to the running processes, they would just >>> be returned to the login prompt. >>> >> vtdaemon does console locking/unlocking on behalf of the console >> session being locked/unlocked. >> If we allow root to unlock the session, no matter it has restricted >> accessibility or not, we should audit >> this unlocking event. This will eventually result in faking a root >> audit context, and that is *not allowed* >> by SUN audit policy. >>> What I never liked was that it meant we needed to give the lab >>> proctors the root password to the lab workstations. >>> Maybe something could be done with with roles, profles, etc. for this? >> The project team believes that the accessibility to the local >> physical consoles should be managed properly. >> If a person is ever allowed to access the local console, he/she >> should be trusted to behave properly. >> Virtual consoles could solve by some degree the situation that a >> person *accidentally* locked several >> of the available virtual consoles, the system administrator could >> login via one of the rest of the available >> consoles and deal with the mess. But if all the available virtual >> consoles are locked out, what should be >> blamed is the management of physical access to the local consoles. > > >> >> -- aaron > From kmcdonald@egenera.com Sun Aug 17 15:55:09 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7HMt91i004379 for ; Sun, 17 Aug 2008 15:55:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7HMt5Ek000784; Sun, 17 Aug 2008 15:55:06 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5R00F0NOZTHS00@brm-avmta-1.central.sun.com>; Sun, 17 Aug 2008 16:55:05 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5R0089GOZSB050@brm-avmta-1.central.sun.com>; Sun, 17 Aug 2008 16:55:05 -0600 (MDT) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7HMt4mB019185; Sun, 17 Aug 2008 22:55:04 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay24i.sun.com with ESMTP id BT-MMP-1906910; Sun, 17 Aug 2008 22:55:04 +0000 (Z) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-59395901; Sun, 17 Aug 2008 22:55:02 +0000 (Z) Received: from webaccess.egenera.com ([63.139.209.15] [63.139.209.15]) by relay23i.sun.com with ESMTP id BT-MMP-14286762; Sun, 17 Aug 2008 22:55:02 +0000 (Z) Received: from [10.50.0.126] ([10.50.0.126]) by webaccess.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 17 Aug 2008 18:55:01 -0400 Date: Sun, 17 Aug 2008 18:55:01 -0400 From: Kyle McDonald Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A79C02.7070207@Sun.COM> To: Aaron Zang Cc: Jeremy Harris , psarc-ext@sun.com, console-core@sun.com, Gary Winiger , Michael Schuster Message-id: <48A8AC45.2040108@Egenera.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 1.747sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> <48A5A4F9.7020307@Egenera.COM> <48A67A55.2060904@Sun.COM> <48A6E062.7050500@wizmail.org> <48A79C02.7070207@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 17 Aug 2008 22:55:01.0477 (UTC) FILETIME=[47C5D950:01C900BC] Status: RO Content-Length: 2325 Aaron Zang wrote: > Jeremy Harris wrote: >> Aaron Zang wrote: >>> If a person is ever allowed to access the local console, he/she >>> should be trusted to behave properly. >>> Virtual consoles could solve by some degree the situation that a >>> person *accidentally* locked several >>> of the available virtual consoles, the system administrator could >>> login via one of the rest of the available >>> consoles and deal with the mess. But if all the available virtual >>> consoles are locked out, what should be >>> blamed is the management of physical access to the local consoles. >> >> All very reasonable for a server-class system. Totally useless for a >> single-monitor, single keyboard system in a student environment. >> > > While in a student environment, it's almost safe to say nothing > important (business/money related) > service is running on that system, so the system admin could even > hammer the system to get it back. > Except for all the jobs of students logged in from home or the dorms through the network, or the long running grad student jobs, that are also running on the machine. They may not be directly Bussiness/Money related, but if the lab proctors (who aren't usually system admins) have to power cycle ot L1-A the machine to unlock the console, then you're going to end up with a bunch of pissed off students who lose work, and eventually some of those will be upset enough to transfer to another school. > The locked system situation is not first introduced by virtual > console, and it's by the nature of locking > screen on a workstation. But all the other methods of locking the screen allow an administrator to override that lock. I agree with you about the audit context, and the ability of whoe ever unlocked the screen to act as whoever left themsleves logged in. I think if it were linked to a privlege (role? profile? authorization?) instead of 'root' that garrets suggestion would probably be best. Then the sysadmin could give the lab proctor accounts this ability, and a utility to clean out the processes on the consoles. Of course another alternative would be something like 'screen' where virtually an unlimited number of virtual conosle could continue to be created, leaving the locked ones and the processes running. -Kyle > > -- aaron From Aaron.Zang@sun.com Sun Aug 17 16:57:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7HNvtlh005122 for ; Sun, 17 Aug 2008 16:57:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7HNvoKX021165; Mon, 18 Aug 2008 00:57:53 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5R00803RWGXI00@nwk-avmta-2.sfbay.sun.com>; Sun, 17 Aug 2008 16:57:52 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5R008PRRW0BP00@nwk-avmta-2.sfbay.sun.com>; Sun, 17 Aug 2008 16:57:52 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7HNvZJb005805; Sun, 17 Aug 2008 23:57:35 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5R00D01RMEPN00@fe-emea-10.sun.com> (original mail from Aaron.Zang@Sun.COM); Mon, 18 Aug 2008 00:57:35 +0100 (BST) Received: from [129.158.217.200] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5R00HENRVRGZ00@fe-emea-10.sun.com>; Mon, 18 Aug 2008 00:57:35 +0100 (BST) Date: Mon, 18 Aug 2008 07:55:51 +0800 From: Aaron Zang Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A8AC45.2040108@Egenera.COM> Sender: Aaron.Zang@sun.com To: Kyle McDonald Cc: Jeremy Harris , psarc-ext@sun.com, console-core@sun.com, Gary Winiger , Michael Schuster Message-id: <48A8BA87.9010601@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> <48A5A4F9.7020307@Egenera.COM> <48A67A55.2060904@Sun.COM> <48A6E062.7050500@wizmail.org> <48A79C02.7070207@Sun.COM> <48A8AC45.2040108@Egenera.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 3295 Kyle McDonald wrote: > Aaron Zang wrote: >> Jeremy Harris wrote: >>> Aaron Zang wrote: >>>> If a person is ever allowed to access the local console, he/she >>>> should be trusted to behave properly. >>>> Virtual consoles could solve by some degree the situation that a >>>> person *accidentally* locked several >>>> of the available virtual consoles, the system administrator could >>>> login via one of the rest of the available >>>> consoles and deal with the mess. But if all the available virtual >>>> consoles are locked out, what should be >>>> blamed is the management of physical access to the local consoles. >>> >>> All very reasonable for a server-class system. Totally useless for a >>> single-monitor, single keyboard system in a student environment. >>> >> >> While in a student environment, it's almost safe to say nothing >> important (business/money related) >> service is running on that system, so the system admin could even >> hammer the system to get it back. >> > Except for all the jobs of students logged in from home or the dorms > through the network, or the long running grad student jobs, that are > also running on the machine. They may not be directly Bussiness/Money > related, but if the lab proctors (who aren't usually system admins) have > to power cycle ot L1-A the machine to unlock the console, then you're > going to end up with a bunch of pissed off students who lose work, and > eventually some of those will be upset enough to transfer to another > school. If the systems are networked, who not let the lab proctors login through the network and do the management? >> The locked system situation is not first introduced by virtual >> console, and it's by the nature of locking >> screen on a workstation. > But all the other methods of locking the screen allow an administrator > to override that lock. > > I agree with you about the audit context, and the ability of whoe ever > unlocked the screen to act as whoever left themsleves logged in. > > I think if it were linked to a privlege (role? profile? authorization?) > instead of 'root' that garrets suggestion would probably be best. Then > the sysadmin could give the lab proctor accounts this ability, and a > utility to clean out the processes on the consoles. > We introduced 2 authorizations smf.management.vt smf.value.vt. They are all granted to the Device Security profile. You can use this profile if you do not want give out "root", or just grant the authorizations to some other role. > Of course another alternative would be something like 'screen' where > virtually an unlimited number of virtual conosle could continue to be > created, leaving the locked ones and the processes running. > Kyle, I think in your case disabling the locking screen feature of virtual console will fit. It would make virtual consoles function a lot like Linux. Or you can grant the smf.management.vt and smf.value.vt authorizations to a role and let that role do the cleaning via network. Does the above solve your problem? I sensed that you naturally do not like root unlock either, because you do not want to give out "root". Your problem is actually RBAC related. -- aaron -- You know some birds are not meant to be caged, their feathers are just too bright. From Nicolas.Williams@sun.com Sun Aug 17 22:49:37 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7I5naKV012417 for ; Sun, 17 Aug 2008 22:49:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7I5nXM5013853; Mon, 18 Aug 2008 13:49:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5S00I0586LXF00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 17 Aug 2008 22:49:33 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5S00H6M86KYM20@nwk-avmta-1.sfbay.Sun.COM>; Sun, 17 Aug 2008 22:49:32 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7I5nUSm019741; Mon, 18 Aug 2008 00:49:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7I5nTkV019740; Mon, 18 Aug 2008 00:49:29 -0500 (CDT) Date: Mon, 18 Aug 2008 00:49:29 -0500 From: Nicolas Williams Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A6E062.7050500@wizmail.org> To: Jeremy Harris Cc: Aaron Zang , Kyle McDonald , PSARC-ext@sun.com, console-core@sun.com, Gary Winiger , Michael Schuster Mail-followup-to: Jeremy Harris , Aaron Zang , Kyle McDonald , PSARC-ext@sun.com, console-core@sun.com, Gary Winiger , Michael Schuster Message-id: <20080818054929.GY17511@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> <48A5A4F9.7020307@Egenera.COM> <48A67A55.2060904@Sun.COM> <48A6E062.7050500@wizmail.org> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 812 On Sat, Aug 16, 2008 at 03:12:50PM +0100, Jeremy Harris wrote: > Aaron Zang wrote: > >If a person is ever allowed to access the local console, he/she > >should be trusted to behave properly. Virtual consoles could solve > >by some degree the situation that a person *accidentally* locked > >several of the available virtual consoles, the system administrator > >could login via one of the rest of the available consoles and deal > >with the mess. But if all the available virtual consoles are locked > >out, what should be blamed is the management of physical access to > >the local consoles. > > All very reasonable for a server-class system. Totally useless for a > single-monitor, single keyboard system in a student environment. In such an environment the sysadmin can surely remotely remove the lock. From Alan.Coopersmith@sun.com Mon Aug 18 08:03:53 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7IF3qbM026334 for ; Mon, 18 Aug 2008 08:03:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7IF3nXi021182; Mon, 18 Aug 2008 16:03:51 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5S0050DXUD7O00@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Aug 2008 08:03:49 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5S00353XUCBG30@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Aug 2008 08:03:48 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7IF3mUN029570; Mon, 18 Aug 2008 08:03:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5S00K01XO5Y800@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM); Mon, 18 Aug 2008 08:03:48 -0700 (PDT) Received: from [10.6.102.118] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5S00HWMXU7WK20@fe-sfbay-10.sun.com>; Mon, 18 Aug 2008 08:03:43 -0700 (PDT) Date: Mon, 18 Aug 2008 08:03:29 -0700 From: Alan Coopersmith Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] In-reply-to: <48A5A4F9.7020307@Egenera.COM> Sender: Alan.Coopersmith@sun.com To: Kyle McDonald Cc: Aaron Zang , Michael Schuster , psarc-ext@sun.com, console-core@sun.com, Gary Winiger Message-id: <48A98F41.5040501@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200808130022.m7D0MFCS007076@sac.sfbay.sun.com> <48A22FA7.2090703@sun.com> <48A23407.8080407@Sun.COM> <48A2F302.2040701@sun.com> <48A37FC1.4000109@Sun.COM> <48A44B24.2090208@sun.com> <48A4CB34.3090207@Sun.COM> <48A5A4F9.7020307@Egenera.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1004 Kyle McDonald wrote: > When Running large computer labs at universities, this root-unlock > feature has been a godsend for when users lock their terminals and leave > the lab, and there are no other workstations available for new users. Though when I was one of the people running a large computer lab at a university, we disabled the root unlock in xlock (it was what everyone used way back then, before CDE) after a student compiled their own xlock that recorded the passwords used to unlock, then left the screen locked waiting for an admin to unlock... after all, if you had the root password, you could also rlogin (or ssh today), su & kill the processes. The feature really is an attractive nuisance, which is why we've been disabling it by default, but leaving it as an option for those customers who insist that in their environment the value is worth the spoofability risk. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gww@sac.sfbay.sun.com Wed Aug 20 16:16:10 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7KNG91P013198 for ; Wed, 20 Aug 2008 16:16:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7KNG2ND012712; Thu, 21 Aug 2008 07:16:08 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5X00H0B9YV7D00@nwk-avmta-2.sfbay.sun.com>; Wed, 20 Aug 2008 16:16:07 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5X007W49YVVID0@nwk-avmta-2.sfbay.sun.com>; Wed, 20 Aug 2008 16:16:07 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7KNG5oo027553; Wed, 20 Aug 2008 16:16:05 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7KNG5cZ013195; Wed, 20 Aug 2008 16:16:05 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m7KNG5iZ013194; Wed, 20 Aug 2008 16:16:05 -0700 (PDT) Date: Wed, 20 Aug 2008 16:16:05 -0700 (PDT) From: Gary Winiger Subject: Re: Virtual Console Update [PSARC/2008/515 FastTrack timeout 08/19/2008] To: gww@sac.sfbay.sun.com, psarc-ext@sun.com Cc: Aaron.Zang@sun.com, console-core@sun.com Message-id: <200808202316.m7KNG5iZ013194@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 485 > I'm sponsoring this fast track for Aaron Zang and the Virtual Console team. > This case proposes to eliminate the vtdaemon "rootunlock" property of > PSARC/2006/591, Virtual Console. The Virtual Console project has not > delivered into any version of OpenSolaris or Solaris so this case > introduces no incompatibilities. This case proposes no change to the > original approved Release Binding of patch/micro. This case was approved as proposed at today's PSARC meeting. Gary..