From Brian.Cameron@sun.com Tue Apr 6 19:56:42 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o372ugVW012416 for ; Tue, 6 Apr 2010 19:56:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o372ufZm026422 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 6 Apr 2010 21:56:41 -0500 (CDT) 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 <0L0H00703K6HT700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Apr 2010 19:56:41 -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 <0L0H004MXK6H1G20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Apr 2010 19:56:41 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o372ueLV016045 for ; Wed, 07 Apr 2010 02:56:40 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0H00700JLF3A00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Apr 2010 20:56:40 -0600 (MDT) Received: from [192.168.1.66] ([unknown] [99.92.178.76]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0H00MRUK65Q390@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Apr 2010 20:56:40 -0600 (MDT) Date: Tue, 06 Apr 2010 21:56:11 -0500 From: Brian Cameron Subject: GDM Integration With audioctl [PSARC/2010/116] Sender: Brian.Cameron@sun.com To: PSARC-ext Cc: Desktop Discuss Message-id: <4BBBF44B.7020200@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_fhVf8eTBlwYIjjxhLhUMQQ)" X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Thunderbird/3.0.3 Status: RO Content-Length: 8030 This is a multi-part message in MIME format. --Boundary_(ID_fhVf8eTBlwYIjjxhLhUMQQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT I have submitted the following case as PSARC 2010/116 with a timeout next Wednesday, April 14th. This is a pretty trivial interface change, so I am not expecting it will require much review. I worked out the details with Garrett D'Amore, and he already reviewed the one-pager and thought it was ready to submit. I have also attached the patch to the GDM PreSession & PostSession script which implements the interface change described in this one-pager in case anybody wants to review it as well. Thanks, Brian --- Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GDM Integration With audioctl 1.2. Name of Document Author/Supplier: Brian Cameron 1.3. Date of This Document: March 06, 2010 1.3.1. Date this project was conceived: March 06, 2010 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: System PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: robert.odea@sun.com 1.4.4. The name of your business unit: Solaris Platform Engineering 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy@sun.com 1.5.2. Responsible Engineer: brian.cameron@sun.com 1.5.3. Marketing Manager: glynn.foster@sun.com 1.5.4. Interest List: desktop-discuss@opensolaris.org 2. Project Summary 2.1 Project Description: This ARC case addresses bugster CR #6606096 by providing a mechanism for the user's audio settings to be saved on logout and re-loaded on login. This ensures that the audio settings are returned to the user's preferred values on reboot or when one user logs out and another user logs in. There has been some discussion with the Device Allocation team about solving this problem at a lower level so that audio preferences are saved and loaded when the audio device is allocated or deallocated. Until a better low-level solution exists, this case provides users with temporary relief. This is needed since many users complain that their audio settings are lost and returned to the default system values each time they reboot their machine. However, this integration will likely be removed if and when a more general solution is available. 4. Technical Description: 4.1. Details: To save the user's audio settings, the GDM PostSession script is modified to save the user's audio settings on logout. The user's audio settings values are stored in the $HOME/.audioctl directory. The PostSession script creates this directory if it is not present and ensures it has 700 permissions and is owned by the user and associated with the user's primary group. The PostSession script then saves the user's audio settings by calling the /usr/bin/audioctl program as follows: /usr/bin/audioctrl save-controls -f $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME The HOSTNAME value is obtained by calling /usr/bin/hostname and the DEVICENAME value is obtained by calling the following command: /usr/bin/audioctl show-device | grep Name | sed 's/.*= *//g' The resulting $HOME/.audioctl/audioctl-$HOMENAME-$DEVICENAME file is created with 600 permissions and also is owned by the user and associated with the user's primary group. This ensures that the audio default settings are saved uniquely per-machine and per-device for each user. Thus, each user who shares their $HOME directory across multiple systems will have discrete settings for each machine and device that they use. The GDM PreSession script loads the settings when the user next logs in by calling this command, constructing the filename in the same manner as described above: /usr/bin/audioctl load-controls $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME 4.2. Bug/RFE Number(s): CR #6606096 4.5. Interfaces: Exported Interface Interface Classification Comments ------------------------- -------------- ---------------------- $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME Volatile User's audio settings Imported Interface Interface Classification ARC case Comment -------- --------------- ---------- ---------------- /usr/bin/audioctl Committed PSARC 2009/626 4.6. Doc Impact: None. 4.7. Admin/Config Impact: None. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: None. This change adds no messages needing translation. 4.10. Packaging & Delivery: Included with GDM. 4.11. Security Impact: File system permissions and ownership are used to ensure that each user's configuration files can not be accessed or modified by other users. 4.12. Dependencies: This solution only works on systems that support OSS. For example, it will not work in Sun Ray environments until they support OSS or on systems that do not have OSS audio driver support. 5. Reference Documents: None. --Boundary_(ID_fhVf8eTBlwYIjjxhLhUMQQ) Content-type: text/plain; name=gdm-26-audio-default.diff Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=gdm-26-audio-default.diff --- gdm-2.30.0/data/PreSession.in-orig 2010-04-01 20:07:33.764844800 -0500 +++ gdm-2.30.0/data/PreSession.in 2010-04-01 20:08:26.004795852 -0500 @@ -7,3 +7,18 @@ # Note that output goes into the .xsession-errors file for easy debugging # PATH="@SCRIPT_PATH@" + +OSS_SAVE_HOSTNAME=`/usr/bin/hostname` +OSS_SAVE_DEVICE="" +OSS_SAVE_DIR="$HOME/.audioctl" + +if test -x "/usr/bin/audioctl" ; then + OSS_SAVE_DEVICE=`/usr/bin/audioctl show-device | /usr/bin/grep Name | /usr/bin/sed 's/.*= *//g'` +fi + +if test -n "$OSS_SAVE_HOSTNAME" -a -n "$OSS_SAVE_DEVICE"; then + OSS_SAVE_FILE="$OSS_SAVE_DIR/audioctl-$OSS_SAVE_HOSTNAME-$OSS_SAVE_DEVICE" + if test -f "$OSS_SAVE_FILE" ; then + /usr/bin/audioctl load-controls $OSS_SAVE_FILE + fi +fi --- gdm-2.30.0/data/PostSession.in-orig 2010-04-01 20:07:40.149431751 -0500 +++ gdm-2.30.0/data/PostSession.in 2010-04-01 20:08:42.805832581 -0500 @@ -1,4 +1,29 @@ #!/bin/sh PATH="@SCRIPT_PATH@" +OSS_SAVE_HOSTNAME=`/usr/bin/hostname` +OSS_SAVE_DEVICE="" +OSS_SAVE_DIR="$HOME/.audioctl" + +if test -x "/usr/bin/audioctl" ; then + OSS_SAVE_DEVICE=`/usr/bin/audioctl show-device | /usr/bin/grep Name | /usr/bin/sed 's/.*= *//g'` +fi + +if test -n "$OSS_SAVE_HOSTNAME" -a -n "$OSS_SAVE_DEVICE"; then + if test ! -d "$OSS_SAVE_DIR" ; then + /usr/bin/mkdir $OSS_SAVE_DIR + /usr/bin/chmod 700 $OSS_SAVE_DIR + /usr/bin/chown $USER $OSS_SAVE_DIR + /usr/bin/chgrp `id -nG $USER` $OSS_SAVE_DIR + fi + + if test -d "$OSS_SAVE_DIR" ; then + OSS_SAVE_FILE="$OSS_SAVE_DIR/audioctl-$OSS_SAVE_HOSTNAME-$OSS_SAVE_DEVICE" + /usr/bin/audioctl save-controls -f $OSS_SAVE_FILE + /usr/bin/chmod 600 $OSS_SAVE_FILE + /usr/bin/chown $USER $OSS_SAVE_FILE + /usr/bin/chgrp `id -nG $USER` $OSS_SAVE_FILE + fi +fi + exit 0 --Boundary_(ID_fhVf8eTBlwYIjjxhLhUMQQ)-- From garrett.damore@oracle.com Tue Apr 6 22:57:59 2010 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 o375vxfm015111 for ; Tue, 6 Apr 2010 22:57:59 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o375vwZR024475; Tue, 6 Apr 2010 22:57:58 -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 <0L0H00D01SKM6W00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 06 Apr 2010 22:57:58 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0H00IK1SKLDH30@nwk-avmta-1.sfbay.Sun.COM>; Tue, 06 Apr 2010 22:57:58 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o375vvrU011163; Wed, 07 Apr 2010 05:57:57 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o375vrIS002166; Wed, 07 Apr 2010 05:57:53 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 152820511270619801; Tue, 06 Apr 2010 22:56:41 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Apr 2010 22:56:41 -0700 Date: Tue, 06 Apr 2010 22:56:40 -0700 From: "Garrett D'Amore" Subject: Re: GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBBF44B.7020200@sun.com> To: Brian Cameron Cc: PSARC-ext , Desktop Discuss Message-id: <4BBC1E98.5080807@oracle.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-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BBC1EE2.008B:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 6145 On 04/ 6/10 07:56 PM, Brian Cameron wrote: > > I have submitted the following case as PSARC 2010/116 with a timeout > next Wednesday, April 14th. > > This is a pretty trivial interface change, so I am not expecting it > will require much review. I worked out the details with Garrett > D'Amore, and he already reviewed the one-pager and thought it was ready > to submit. > > I have also attached the patch to the GDM PreSession & PostSession > script which implements the interface change described in this > one-pager in case anybody wants to review it as well. Thanks Brian. +1 from me on this case. :-) - Garrett > > Thanks, > > Brian > > --- > > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2007 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: > > GDM Integration With audioctl > > 1.2. Name of Document Author/Supplier: > > Brian Cameron > > 1.3. Date of This Document: > > March 06, 2010 > > 1.3.1. Date this project was conceived: > > March 06, 2010 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > > 1.4.1. The PAC or CPT you expect to review your project: > > System PAC > > 1.4.2. The ARC(s) you expect to review your project: > > PSARC > > 1.4.3. The Director/VP who is "Sponsoring" this project: > > robert.odea@sun.com > > 1.4.4. The name of your business unit: > > Solaris Platform Engineering > > 1.5. Email Aliases: > > 1.5.1. Responsible Manager: > > leo.binchy@sun.com > > 1.5.2. Responsible Engineer: > > brian.cameron@sun.com > > 1.5.3. Marketing Manager: > > glynn.foster@sun.com > > 1.5.4. Interest List: > > desktop-discuss@opensolaris.org > > 2. Project Summary > > 2.1 Project Description: > > This ARC case addresses bugster CR #6606096 by providing a > mechanism for the user's audio settings to be saved on logout and > re-loaded on login. This ensures that the audio settings are > returned to the user's preferred values on reboot or when one user > logs out and another user logs in. > > There has been some discussion with the Device Allocation team about > solving this problem at a lower level so that audio preferences are > saved and loaded when the audio device is allocated or > deallocated. Until a better low-level solution exists, this case > provides users with temporary relief. This is needed since many > users complain that their audio settings are lost and returned to > the default system values each time they reboot their machine. > However, this integration will likely be removed if and when a more > general solution is available. > > 4. Technical Description: > > 4.1. Details: > > To save the user's audio settings, the GDM PostSession script > is modified to save the user's audio settings on logout. > > The user's audio settings values are stored in the > $HOME/.audioctl directory. The PostSession script creates > this directory if it is not present and ensures it has 700 > permissions and is owned by the user and associated with the > user's primary group. > > The PostSession script then saves the user's audio settings by > calling the /usr/bin/audioctl program as follows: > > /usr/bin/audioctrl save-controls -f > $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME > > The HOSTNAME value is obtained by calling /usr/bin/hostname and > the DEVICENAME value is obtained by calling the following > command: > > /usr/bin/audioctl show-device | grep Name | sed 's/.*= *//g' > > The resulting $HOME/.audioctl/audioctl-$HOMENAME-$DEVICENAME > file is created with 600 permissions and also is owned by the > user and associated with the user's primary group. > > This ensures that the audio default settings are saved uniquely > per-machine and per-device for each user. Thus, each user who > shares their $HOME directory across multiple systems will have > discrete settings for each machine and device that they use. > > The GDM PreSession script loads the settings when the user > next logs in by calling this command, constructing the > filename in the same manner as described above: > > /usr/bin/audioctl load-controls > $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME > > 4.2. Bug/RFE Number(s): > > CR #6606096 > > 4.5. Interfaces: > > Exported Interface > > Interface Classification Comments > ------------------------- -------------- ---------------------- > $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME > Volatile User's audio > settings > > Imported Interface > > Interface Classification ARC case Comment > -------- --------------- ---------- ---------------- > /usr/bin/audioctl Committed PSARC 2009/626 > > 4.6. Doc Impact: > > None. > > 4.7. Admin/Config Impact: > > None. > > 4.8. HA Impact: > > None. > > 4.9. I18N/L10N Impact: > > None. This change adds no messages needing translation. > > 4.10. Packaging & Delivery: > > Included with GDM. > > 4.11. Security Impact: > > File system permissions and ownership are used to ensure that > each user's configuration files can not be accessed or > modified by other users. > > 4.12. Dependencies: > > This solution only works on systems that support OSS. For > example, it will not work in Sun Ray environments until they > support OSS or on systems that do not have OSS audio driver > support. > > 5. Reference Documents: > > None. > From mike.oliver@oracle.com Wed Apr 7 01:26:56 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o378QtCX004530 for ; Wed, 7 Apr 2010 01:26:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o378Qslx008651; Wed, 7 Apr 2010 03:26:55 -0500 (CDT) 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 <0L0H0070JZGVAM00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 07 Apr 2010 01:26:55 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0H00IJCZGUDHE0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 07 Apr 2010 01:26:54 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o378QsEV013329; Wed, 07 Apr 2010 08:26:54 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o36MGvAj011275; Wed, 07 Apr 2010 08:26:46 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 142187181270628797; Wed, 07 Apr 2010 01:26:37 -0700 Received: from [192.168.1.2] (/98.210.247.45) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 01:26:37 -0700 Date: Wed, 07 Apr 2010 01:26:29 -0700 From: Mike Oliver Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBBF44B.7020200@sun.com> To: Brian Cameron Cc: PSARC-ext , Desktop Discuss Message-id: <4BBC41B5.9020702@oracle.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-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B020A.4BBC41C8.030F:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Status: RO Content-Length: 6854 On 4/6/2010 7:56 PM, Brian Cameron wrote: > > I have submitted the following case as PSARC 2010/116 with a timeout > next Wednesday, April 14th. > > This is a pretty trivial interface change, so I am not expecting it > will require much review. I worked out the details with Garrett > D'Amore, and he already reviewed the one-pager and thought it was ready > to submit. You're proposing to modify the Default PreSession and PostSession scripts, right? Not a display-specific script? PreSession and PostSession scripts are executed as root. Do these scripts arrange to execute 'audioctl' as the logged-in (and logging-out) user? I don't see this happening in the patch. Are any measures taken to defend against someone logging in as root (or some other suitably-privileged user) while someone else is using the audio device and therefore clobbering the settings of the user who really owns the audio device? (I know root is a role by default. That doesn't prevent people from converting it back to a normal login account. Obviously this is a bigger issue if these scripts don't run 'audioctl' as $USER.) PSARC 2009/626 says that the device name that is retrieved by 'audioctl show-device' is sensitive to $AUDIODEV, but PostSession (and probably PreSession) has no knowledge of what $AUDIODEV was set to in the user's session. Is it fair to say that this case will only attempt to save and restore the settings of the default audio device, which is not necessarily the device that the user session will use? The 'audioctl show-device' output consumed by this case was declared as "Not An Interface" in PSARC 2009/626. Has the Stability of that output been changed since then? Does GDM guarantee to set $HOME appropriately for these scripts? I know it sets $USER, I can't find anything that guarantees $HOME. Code review nit: using both 'grep' and 'sed' in a single pipeline is rarely necessary. Mike. -- mike.oliver@oracle.com > I have also attached the patch to the GDM PreSession & PostSession > script which implements the interface change described in this > one-pager in case anybody wants to review it as well. > > Thanks, > > Brian > > --- > > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2007 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: > > GDM Integration With audioctl > > 1.2. Name of Document Author/Supplier: > > Brian Cameron > > 1.3. Date of This Document: > > March 06, 2010 > > 1.3.1. Date this project was conceived: > > March 06, 2010 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > > 1.4.1. The PAC or CPT you expect to review your project: > > System PAC > > 1.4.2. The ARC(s) you expect to review your project: > > PSARC > > 1.4.3. The Director/VP who is "Sponsoring" this project: > > robert.odea@sun.com > > 1.4.4. The name of your business unit: > > Solaris Platform Engineering > > 1.5. Email Aliases: > > 1.5.1. Responsible Manager: > > leo.binchy@sun.com > > 1.5.2. Responsible Engineer: > > brian.cameron@sun.com > > 1.5.3. Marketing Manager: > > glynn.foster@sun.com > > 1.5.4. Interest List: > > desktop-discuss@opensolaris.org > > 2. Project Summary > > 2.1 Project Description: > > This ARC case addresses bugster CR #6606096 by providing a > mechanism for the user's audio settings to be saved on logout and > re-loaded on login. This ensures that the audio settings are > returned to the user's preferred values on reboot or when one user > logs out and another user logs in. > > There has been some discussion with the Device Allocation team about > solving this problem at a lower level so that audio preferences are > saved and loaded when the audio device is allocated or > deallocated. Until a better low-level solution exists, this case > provides users with temporary relief. This is needed since many > users complain that their audio settings are lost and returned to > the default system values each time they reboot their machine. > However, this integration will likely be removed if and when a more > general solution is available. > > 4. Technical Description: > > 4.1. Details: > > To save the user's audio settings, the GDM PostSession script > is modified to save the user's audio settings on logout. > > The user's audio settings values are stored in the > $HOME/.audioctl directory. The PostSession script creates > this directory if it is not present and ensures it has 700 > permissions and is owned by the user and associated with the > user's primary group. > > The PostSession script then saves the user's audio settings by > calling the /usr/bin/audioctl program as follows: > > /usr/bin/audioctrl save-controls -f > $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME > > The HOSTNAME value is obtained by calling /usr/bin/hostname and > the DEVICENAME value is obtained by calling the following > command: > > /usr/bin/audioctl show-device | grep Name | sed 's/.*= *//g' > > The resulting $HOME/.audioctl/audioctl-$HOMENAME-$DEVICENAME > file is created with 600 permissions and also is owned by the > user and associated with the user's primary group. > > This ensures that the audio default settings are saved uniquely > per-machine and per-device for each user. Thus, each user who > shares their $HOME directory across multiple systems will have > discrete settings for each machine and device that they use. > > The GDM PreSession script loads the settings when the user > next logs in by calling this command, constructing the > filename in the same manner as described above: > > /usr/bin/audioctl load-controls > $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME > > 4.2. Bug/RFE Number(s): > > CR #6606096 > > 4.5. Interfaces: > > Exported Interface > > Interface Classification Comments > ------------------------- -------------- ---------------------- > $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME > Volatile User's audio > settings > > Imported Interface > > Interface Classification ARC case Comment > -------- --------------- ---------- ---------------- > /usr/bin/audioctl Committed PSARC 2009/626 > > 4.6. Doc Impact: > > None. > > 4.7. Admin/Config Impact: > > None. > > 4.8. HA Impact: > > None. > > 4.9. I18N/L10N Impact: > > None. This change adds no messages needing translation. > > 4.10. Packaging & Delivery: > > Included with GDM. > > 4.11. Security Impact: > > File system permissions and ownership are used to ensure that > each user's configuration files can not be accessed or > modified by other users. > > 4.12. Dependencies: > > This solution only works on systems that support OSS. For > example, it will not work in Sun Ray environments until they > support OSS or on systems that do not have OSS audio driver > support. > > 5. Reference Documents: > > None. > > > > _______________________________________________ > desktop-discuss mailing list > desktop-discuss@opensolaris.org From garrett.damore@oracle.com Wed Apr 7 08:01:55 2010 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 o37F1tJv010377 for ; Wed, 7 Apr 2010 08:01:55 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37F1sQq009969; Wed, 7 Apr 2010 08:01:55 -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 <0L0I00901HR6S200@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 09:01:54 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I0064MHR5O630@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 09:01:53 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o37F1rQn000224; Wed, 07 Apr 2010 15:01:53 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o37F1l77011859; Wed, 07 Apr 2010 15:01:47 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt354.oracle.com with ESMTP id 154377331270652479; Wed, 07 Apr 2010 08:01:19 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 08:01:19 -0700 Date: Wed, 07 Apr 2010 08:01:18 -0700 From: "Garrett D'Amore" Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBC41B5.9020702@oracle.com> To: Mike Oliver Cc: Brian Cameron , PSARC-ext , Desktop Discuss Message-id: <4BBC9E3E.9000706@oracle.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-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BBC9E5E.003A:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 2858 Mike, you raise good issues. I was not aware of the environment which PreSession and PostSession took place. I'd like these issues resolved, and am withdrawing my +1 until they are properly satisfied. As far as the output from audioctl show-device goes, we can handle that in one of two ways: 1) add a contract for the interfaces use. I can arrange for my mgmt to sign off on it. 2) increase the commitment level for just that subcommand. I'd be ok with raising it to Uncommitted. Actually, looking at the output, I think they are just using the Device: field from the command, which is simple and parseable enough that I'm willing to agree that at least *that* portion of it will never change. Its the other results that (HW Info, etc.) that are potentially subject to change. - Garrett On 04/ 7/10 01:26 AM, Mike Oliver wrote: > On 4/6/2010 7:56 PM, Brian Cameron wrote: >> >> I have submitted the following case as PSARC 2010/116 with a timeout >> next Wednesday, April 14th. >> >> This is a pretty trivial interface change, so I am not expecting it >> will require much review. I worked out the details with Garrett >> D'Amore, and he already reviewed the one-pager and thought it was ready >> to submit. > > You're proposing to modify the Default PreSession and PostSession > scripts, > right? Not a display-specific script? > > PreSession and PostSession scripts are executed as root. Do these > scripts > arrange to execute 'audioctl' as the logged-in (and logging-out) user? I > don't see this happening in the patch. > > Are any measures taken to defend against someone logging in as root (or > some other suitably-privileged user) while someone else is using the > audio device and therefore clobbering the settings of the user who > really owns the audio device? (I know root is a role by default. That > doesn't prevent people from converting it back to a normal login > account. Obviously this is a bigger issue if these scripts don't run > 'audioctl' as $USER.) > > PSARC 2009/626 says that the device name that is retrieved by > 'audioctl show-device' is sensitive to $AUDIODEV, but PostSession (and > probably PreSession) has no knowledge of what $AUDIODEV was set to in > the user's session. Is it fair to say that this case will only attempt > to save and restore the settings of the default audio device, which is > not necessarily the device that the user session will use? > > The 'audioctl show-device' output consumed by this case was declared as > "Not An Interface" in PSARC 2009/626. Has the Stability of that output > been changed since then? > > Does GDM guarantee to set $HOME appropriately for these scripts? I know > it sets $USER, I can't find anything that guarantees $HOME. > > Code review nit: using both 'grep' and 'sed' in a single pipeline is > rarely necessary. > > Mike. From brian.cameron@oracle.com Wed Apr 7 08:06:09 2010 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 o37F68Id010521 for ; Wed, 7 Apr 2010 08:06:08 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37F68er023706; Wed, 7 Apr 2010 08:06:08 -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 <0L0I00A05HY87R00@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 09:06:08 -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 <0L0I006V3HY7O720@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 09:06:07 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o37F67DO001073; Wed, 07 Apr 2010 15:06:07 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o37D60UM010622; Wed, 07 Apr 2010 15:06:00 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 154388031270652670; Wed, 07 Apr 2010 08:04:30 -0700 Received: from [192.168.1.66] (/99.63.93.167) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 08:04:29 -0700 Date: Wed, 07 Apr 2010 10:04:08 -0500 From: Brian Cameron Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBC41B5.9020702@oracle.com> To: Mike Oliver Cc: Brian Cameron , PSARC-ext , Desktop Discuss Message-id: <4BBC9EE8.10006@oracle.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-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BBC9F59.00D0:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Thunderbird/3.0.3 Status: RO Content-Length: 3627 Mike: > You're proposing to modify the Default PreSession and PostSession scripts, > right? Not a display-specific script? Correct. If display-specific scripts want the functionality in the Default script, they must run the Default script. > PreSession and PostSession scripts are executed as root. Do these scripts > arrange to execute 'audioctl' as the logged-in (and logging-out) user? I > don't see this happening in the patch. I did not feel that is necessary since the audioctl functions being called are specific and not dangerous, but this seems a reasonable change. Would the best way to do this be to call: su - $USER -c "/usr/bin/audioctl (args)" Or is there a better way to do this? > Are any measures taken to defend against someone logging in as root (or > some other suitably-privileged user) while someone else is using the > audio device and therefore clobbering the settings of the user who > really owns the audio device? (I know root is a role by default. That > doesn't prevent people from converting it back to a normal login > account. Obviously this is a bigger issue if these scripts don't run > 'audioctl' as $USER.) audioctl will only work if the user has permissions to the audio device. Since logindevperm only allows a single user to have access to the audio device at a time, this normally should never be a problem. However, you are right, if a user logs in as the root user after logging in as a different user, then the root user's audio settings would clobber the device. Also, there could be problems if logindevperm is configured to set the audio device to 660 or 666 permissions to allow multiple users to have access. The PreSession script could check the ownership of /dev/audio and only call "audioctl load-controls" if /dev/audio is already owned by the user. It is a bit of a drag to follow all the /dev/audio symlinks, but it would be smarter. > PSARC 2009/626 says that the device name that is retrieved by > 'audioctl show-device' is sensitive to $AUDIODEV, but PostSession (and > probably PreSession) has no knowledge of what $AUDIODEV was set to in > the user's session. Is it fair to say that this case will only attempt > to save and restore the settings of the default audio device, which is > not necessarily the device that the user session will use? The code to load the settings could be moved to the /etc/gdm/Xsession script after it sources the user's $HOME/.profile so that if the user sets $AUDIODEV there, it would be honored. Would this be a reasonable solution? Note that this /etc/gdm/Xsession script runs as the user rather than root, but this shouldn't be a problem. Note that even with this solution it is good to only load the settings if /dev/audio is owned by the user to protect from clobbering if logging in as the root user or if logindevperm is configured to set the audio device to 660 or 666 permissions. > The 'audioctl show-device' output consumed by this case was declared as > "Not An Interface" in PSARC 2009/626. Has the Stability of that output > been changed since then? Garrett? Is there a better ay to get the device name? > Does GDM guarantee to set $HOME appropriately for these scripts? I know > it sets $USER, I can't find anything that guarantees $HOME. It does set $HOME, and I do not expect that will change. > Code review nit: using both 'grep' and 'sed' in a single pipeline is > rarely necessary. You are likely more of a sed god than I. Want to tell me how offline and I can easily improve the script this way. Though, this is probably not a deal breaker for this case either way I'd think. Brian From Darren.Moffat@oracle.com Wed Apr 7 08:13:43 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o37FDgPt010710 for ; Wed, 7 Apr 2010 08:13:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37FDgxx029036; Wed, 7 Apr 2010 10:13:42 -0500 (CDT) 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 <0L0I00A03IAUXQ00@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 09:13:42 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I006ABIAUO730@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 09:13:42 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o37FDfHL018779; Wed, 07 Apr 2010 15:13:41 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o37AwOqB015132; Wed, 07 Apr 2010 15:13:30 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 143194151270653146; Wed, 07 Apr 2010 08:12:26 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 08:12:25 -0700 Date: Wed, 07 Apr 2010 16:12:21 +0100 From: Darren J Moffat Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBC9EE8.10006@oracle.com> To: Brian Cameron Cc: Mike Oliver , PSARC-ext , Desktop Discuss , Brian Cameron Message-id: <4BBCA0D5.1060902@Oracle.COM> Organization: Oracle Solaris Security 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-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0207.4BBCA11A.029F:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> <4BBC9EE8.10006@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1242 On 07/04/2010 16:04, Brian Cameron wrote: > I did not feel that is necessary since the audioctl functions being > called are specific and not dangerous, but this seems a reasonable > change. Would the best way to do this be to call: > > su - $USER -c "/usr/bin/audioctl (args)" It would be if su(1M) actually had a documented "-c" argument. That will work though. > The PreSession script could check the ownership of /dev/audio and only > call "audioctl load-controls" if /dev/audio is already owned by the > user. It is a bit of a drag to follow all the /dev/audio symlinks, > but it would be smarter. It it runs as the user logging in that wouldn't be necessary since the user won't be able to change the settings if logindevperm didn't give them access to the devices. > The code to load the settings could be moved to the /etc/gdm/Xsession > script after it sources the user's $HOME/.profile so that if the user > sets $AUDIODEV there, it would be honored. Would this be a reasonable > solution? Note that this /etc/gdm/Xsession script runs as the user > rather than root, but this shouldn't be a problem. That sounds like a better place to me since it avoids the 'su' and it runs in the users environment. -- Darren J Moffat From trisk@opensolaris.org Wed Apr 7 10:40:06 2010 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 o37He6Lf017032 for ; Wed, 7 Apr 2010 10:40:06 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37He3rl014511 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Apr 2010 10:40:05 -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 <0L0I00217P2TKG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Apr 2010 11:40:05 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I006GFP2SOLD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Apr 2010 11:40:04 -0600 (MDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o37He4VO023893 for ; Wed, 07 Apr 2010 17:40:04 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-3763586 for PSARC-ext@sun.com; Wed, 07 Apr 2010 17:40:04 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-76678097 for PSARC-ext@sun.com; Wed, 07 Apr 2010 17:40:03 +0000 (Z) Received: from rcmdxobspool1.cavtel.net ([67.62.218.106] [67.62.218.106]) by relay4i.sun.com with ESMTP id BT-MMP-30833828 for PSARC-ext@sun.com; Wed, 07 Apr 2010 17:40:03 +0000 (Z) Received: from localhost (rcmdvxcm1-ob1.mail-ops.cavtel.net [192.168.247.86]) by rcmdxobspool1.cavtel.net (Postfix) with ESMTP id 709411B800D for ; Wed, 07 Apr 2010 13:40:00 -0400 (EDT) Received: from rcmdxob1.cavtel.net ([127.0.0.1]) by localhost (rcmdxob1.cavtel.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vHIlOKqnjdXI for ; Wed, 07 Apr 2010 13:39:54 -0400 (EDT) Received: from mail.deadgerbil.com (static-98-140-245-86.dsl.cavtel.net [98.140.245.86]) by rcmdxob1.cavtel.net (Postfix) with ESMTP id EC51DEAA65 for ; Wed, 07 Apr 2010 13:39:53 -0400 (EDT) Received: from DSPAM (localhost [127.0.0.1]) by mail.deadgerbil.com (Postfix) with SMTP id A2B7F23A8 for ; Wed, 07 Apr 2010 13:39:49 -0400 (EDT) Received: from mail.deadgerbil.com (localhost [127.0.0.1]) by mail.deadgerbil.com (Postfix) with ESMTP id 45C3A23A2; Wed, 07 Apr 2010 13:39:48 -0400 (EDT) Date: Wed, 07 Apr 2010 13:39:47 -0400 From: Albert Lee Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBC9EE8.10006@oracle.com> X-Sender: trisk@opensolaris.org To: Brian Cameron Cc: Mike Oliver , PSARC-ext , Desktop Discuss , Brian Cameron Message-id: MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: Debian amavisd-new at rcmdxob1.cavtel.net X-Evil: No X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Apr 7 13:39:49 2010 X-DSPAM-Confidence: 0.9983 X-DSPAM-Probability: -1.0000 X-DSPAM-Signature: 4bbcc36538620701046 X-Antispam: No, score=-2.6/5.0, scanned in 0.108sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> <4BBC9EE8.10006@oracle.com> User-Agent: RoundCube Webmail/0.3-trunk Status: RO Content-Length: 4650 On Wed, 07 Apr 2010 10:04:08 -0500, Brian Cameron wrote: > Mike: > >> You're proposing to modify the Default PreSession and PostSession >> scripts, >> right? Not a display-specific script? > > Correct. If display-specific scripts want the functionality in the > Default script, they must run the Default script. > >> PreSession and PostSession scripts are executed as root. Do these scripts >> arrange to execute 'audioctl' as the logged-in (and logging-out) user? I >> don't see this happening in the patch. > > I did not feel that is necessary since the audioctl functions being > called are specific and not dangerous, but this seems a reasonable > change. Would the best way to do this be to call: > > su - $USER -c "/usr/bin/audioctl (args)" > > Or is there a better way to do this? > >> Are any measures taken to defend against someone logging in as root (or >> some other suitably-privileged user) while someone else is using the >> audio device and therefore clobbering the settings of the user who >> really owns the audio device? (I know root is a role by default. That >> doesn't prevent people from converting it back to a normal login >> account. Obviously this is a bigger issue if these scripts don't run >> 'audioctl' as $USER.) > > audioctl will only work if the user has permissions to the audio > device. Since logindevperm only allows a single user to have access > to the audio device at a time, this normally should never be a problem. > > However, you are right, if a user logs in as the root user after > logging in as a different user, then the root user's audio settings > would clobber the device. Also, there could be problems if > logindevperm is configured to set the audio device to 660 or 666 > permissions to allow multiple users to have access. > > The PreSession script could check the ownership of /dev/audio and only > call "audioctl load-controls" if /dev/audio is already owned by the > user. It is a bit of a drag to follow all the /dev/audio symlinks, > but it would be smarter. > Something that may have to be addressed eventually is dynamic switching between multiple X sessions ("fast user switching"). Maybe a note should be made that the design here will have to be revisited if this is ever supported. >> PSARC 2009/626 says that the device name that is retrieved by >> 'audioctl show-device' is sensitive to $AUDIODEV, but PostSession (and >> probably PreSession) has no knowledge of what $AUDIODEV was set to in >> the user's session. Is it fair to say that this case will only attempt >> to save and restore the settings of the default audio device, which is >> not necessarily the device that the user session will use? > > The code to load the settings could be moved to the /etc/gdm/Xsession > script after it sources the user's $HOME/.profile so that if the user > sets $AUDIODEV there, it would be honored. Would this be a reasonable > solution? Note that this /etc/gdm/Xsession script runs as the user > rather than root, but this shouldn't be a problem. > > Note that even with this solution it is good to only load the settings > if /dev/audio is owned by the user to protect from clobbering if > logging in as the root user or if logindevperm is configured to set > the audio device to 660 or 666 permissions. > >> The 'audioctl show-device' output consumed by this case was declared as >> "Not An Interface" in PSARC 2009/626. Has the Stability of that output >> been changed since then? > > Garrett? Is there a better ay to get the device name? > One policy assumption you could make is that users will want the mixer preferences for every device rather than just the primary to be remembered if AUDIODEV isn't set - in that case 'audioctl list-device' could be used. This would be the least surprising behaviour if it becomes possible to dynamically change the primary audio device in the future. I don't know the commitment on /dev/sndstat (like show-device, it would make a poor programmatic interface), but that is another possibility. > > Does GDM guarantee to set $HOME appropriately for these scripts? I know > > it sets $USER, I can't find anything that guarantees $HOME. > > It does set $HOME, and I do not expect that will change. > > > Code review nit: using both 'grep' and 'sed' in a single pipeline is > > rarely necessary. > > You are likely more of a sed god than I. Want to tell me how offline > and I can easily improve the script this way. Though, this is > probably not a deal breaker for this case either way I'd think. > > Brian How about: audioctl show-device | awk '/^ *Name /{ print $3; }' -Albert From brian.cameron@oracle.com Wed Apr 7 13:40:36 2010 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 o37Keanm021954 for ; Wed, 7 Apr 2010 13:40:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o37KeZuP040584; Wed, 7 Apr 2010 14:40:35 -0600 (MDT) 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 <0L0I00K0VXFNWH00@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 14:40:35 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I0058PXFMCJ90@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 14:40:34 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o37KeYlS008605; Wed, 07 Apr 2010 20:40:34 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o37KeSgG000786; Wed, 07 Apr 2010 20:40:28 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 144087381270672746; Wed, 07 Apr 2010 13:39:06 -0700 Received: from [129.150.13.116] (/129.150.13.116) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 13:39:05 -0700 Date: Wed, 07 Apr 2010 15:38:41 -0500 From: Brian Cameron Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBC9E3E.9000706@oracle.com> To: "Garrett D'Amore" Cc: Mike Oliver , Brian Cameron , PSARC-ext , Desktop Discuss Message-id: <4BBCED51.4070904@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_rq9b5Nr1YBYlVXaByBUVkA)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BBCEDBD.008D:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> <4BBC9E3E.9000706@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Thunderbird/3.0.3 Status: RO Content-Length: 13638 This is a multi-part message in MIME format. --Boundary_(ID_rq9b5Nr1YBYlVXaByBUVkA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Garrett/Mike/Albert: I have attached an updated 1-pager and also updated the 1-pager in the case directory. I have also attached a new patch which implements the following changes for review: 1) In the PostSession script the calls to mkdir and "audioctl save-controls" are now called with "/usr/binsu - $USER -c (cmd)" so that the commands which create directories and files are run as the user. 2) The code to load the audio settings is now done in the /etc/gdm/Xsession script after the user's $HOME/.profile is sourced to ensure that any $AUDIODEV settings are honored on login. 3) The PostSession script and the Xsession script now call "/usr/bin/stat -L /dev/audio -c %U" to find out the owner of the audio device, and will only load or save the data if the user is actually the owner of the device. This ensures that only the user who actually has access to the device is modifying the audio device settings. 4) Now, as suggested by Albert, the command to get the device is: /usr/bin/audioctl show-device | /usr/bin/awk '/^ *Name /{ print $3; }' Rather than using grep and sed, so that is a bit simpler. I believe this should resolve all the issues raised about this change. If a contract is needed to use "audioctl show-device" as described in this case, then that is okay with me. Yes, this change only needs to access the are "Device" value, which Garrett indicates should be stable. Brian On 04/ 7/10 10:01 AM, Garrett D'Amore wrote: > Mike, you raise good issues. I was not aware of the environment which > PreSession and PostSession took place. I'd like these issues resolved, > and am withdrawing my +1 until they are properly satisfied. > > As far as the output from audioctl show-device goes, we can handle that > in one of two ways: > > 1) add a contract for the interfaces use. I can arrange for my mgmt to > sign off on it. > > 2) increase the commitment level for just that subcommand. I'd be ok > with raising it to Uncommitted. > > Actually, looking at the output, I think they are just using the Device: > field from the command, which is simple and parseable enough that I'm > willing to agree that at least *that* portion of it will never change. > Its the other results that (HW Info, etc.) that are potentially subject > to change. > > - Garrett > > On 04/ 7/10 01:26 AM, Mike Oliver wrote: >> On 4/6/2010 7:56 PM, Brian Cameron wrote: >>> >>> I have submitted the following case as PSARC 2010/116 with a timeout >>> next Wednesday, April 14th. >>> >>> This is a pretty trivial interface change, so I am not expecting it >>> will require much review. I worked out the details with Garrett >>> D'Amore, and he already reviewed the one-pager and thought it was ready >>> to submit. >> >> You're proposing to modify the Default PreSession and PostSession >> scripts, >> right? Not a display-specific script? >> >> PreSession and PostSession scripts are executed as root. Do these scripts >> arrange to execute 'audioctl' as the logged-in (and logging-out) user? I >> don't see this happening in the patch. >> >> Are any measures taken to defend against someone logging in as root (or >> some other suitably-privileged user) while someone else is using the >> audio device and therefore clobbering the settings of the user who >> really owns the audio device? (I know root is a role by default. That >> doesn't prevent people from converting it back to a normal login >> account. Obviously this is a bigger issue if these scripts don't run >> 'audioctl' as $USER.) >> >> PSARC 2009/626 says that the device name that is retrieved by >> 'audioctl show-device' is sensitive to $AUDIODEV, but PostSession (and >> probably PreSession) has no knowledge of what $AUDIODEV was set to in >> the user's session. Is it fair to say that this case will only attempt >> to save and restore the settings of the default audio device, which is >> not necessarily the device that the user session will use? >> >> The 'audioctl show-device' output consumed by this case was declared as >> "Not An Interface" in PSARC 2009/626. Has the Stability of that output >> been changed since then? >> >> Does GDM guarantee to set $HOME appropriately for these scripts? I know >> it sets $USER, I can't find anything that guarantees $HOME. >> >> Code review nit: using both 'grep' and 'sed' in a single pipeline is >> rarely necessary. >> >> Mike. > --Boundary_(ID_rq9b5Nr1YBYlVXaByBUVkA) Content-type: text/plain; name=gdm-audioctl-one-pager.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=gdm-audioctl-one-pager.txt Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GDM Integration With audioctl 1.2. Name of Document Author/Supplier: Brian Cameron 1.3. Date of This Document: March 06, 2010 1.3.1. Date this project was conceived: March 06, 2010 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: System PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: robert.odea@sun.com 1.4.4. The name of your business unit: Solaris Platform Engineering 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy@sun.com 1.5.2. Responsible Engineer: brian.cameron@sun.com 1.5.3. Marketing Manager: glynn.foster@sun.com 1.5.4. Interest List: desktop-discuss@opensolaris.org 2. Project Summary 2.1 Project Description: This ARC case addresses bugster CR #6606096 by providing a mechanism for the user's audio settings to be saved on logout and re-loaded on login. This ensures that the audio settings are returned to the user's preferred values on reboot or when one user logs out and another user logs in. There has been some discussion with the Device Allocation team about solving this problem at a lower level so that audio preferences are saved and loaded when the audio device is allocated or deallocated. Until a better low-level solution exists, this case provides users with temporary relief. This is needed since many users complain that their audio settings are lost and returned to the default system values each time they reboot their machine. However, this integration will likely be removed if and when a more general solution is available. 4. Technical Description: 4.1. Details: To save the user's audio settings, the GDM PostSession script is modified to save the user's audio settings on logout. The user's settings are only saved if "/usr/bin/stat -L /dev/audio -c %U" reports that the audio device is currently owned by the user. Since logindevperm(4) ensures that only one user has ownership of the device at a time, this will only save the settings when the user is actually able to access the audio device. The user's audio settings values are stored in the $HOME/.audioctl directory. The PostSession script creates this directory if it does not exist and ensures it has 700 permissions. The PostSession script then saves the user's audio settings by calling the /usr/bin/audioctl program as follows: /usr/bin/audioctrl save-controls -f $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME The HOSTNAME value is obtained by calling /usr/bin/hostname and the DEVICENAME value is obtained by calling the following command: /usr/bin/audioctl show-device | /usr/bin/awk '/^ *Name /{ print $3; }' The resulting $HOME/.audioctl/audioctl-$HOMENAME-$DEVICENAME file is created with 600 permissions. This ensures that the audio default settings are saved uniquely per-machine and per-device for each user. Thus, each user who shares their $HOME directory across multiple systems will have discrete settings for each machine and device that they use. The PostSession script runs as the root user, but the commands to make the $HOME/.audioctl directory and to call audioctl with the save-controls operand are run as the user to ensure that all directories and files are created as the user. The GDM /etc/gdm/Xsession script is modified to load the settings when the user next logs in. Again, the user's settings are only loaded if "/usr/bin/stat -L /dev/audio -c %U" reports that the audio device is currently owned by the user. This ensures that if multiple users log in who have access to the audio device that only one user's settings (the actual owner of the device) are honored at a time. For example, this can happen if logindevperm(4) is configured to set the audio device to 660 or 666 permissions. The settings are loaded by calling the following command, constructing the filename in the same manner as described above: /usr/bin/audioctl load-controls $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME 4.2. Bug/RFE Number(s): CR #6606096 4.5. Interfaces: Exported Interface Interface Classification Comments ----------------------------- -------------- ---------------------- $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME Volatile User's audio settings Imported Interface Interface Classification ARC case Comment -------- --------------- ---------- ---------------- /usr/bin/audioctl Committed PSARC 2009/626 4.6. Doc Impact: None. 4.7. Admin/Config Impact: None. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: None. This change adds no messages needing translation. 4.10. Packaging & Delivery: Included with GDM. 4.11. Security Impact: File system permissions and ownership are used to ensure that each user's configuration files can not be accessed or modified by other users. 4.12. Dependencies: This solution only works on systems that support OSS. For example, it will not work in Sun Ray environments until they support OSS or on systems that do not have OSS audio driver support. 5. Reference Documents: None. --Boundary_(ID_rq9b5Nr1YBYlVXaByBUVkA) Content-type: text/plain; name=gdm-26-audio-default.diff Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=gdm-26-audio-default.diff --- gdm-2.30.0/data/Xsession.in-orig 2010-04-07 15:12:25.882247407 -0500 +++ gdm-2.30.0/data/Xsession.in 2010-04-07 15:12:57.139892497 -0500 @@ -70,6 +70,30 @@ gdmwhich () { echo "$OUTPUT" } +# Reload audio settings after sourcing the user's .profile to ensure that any +# AUDIODEV settings defined by the user are honored. +# +AUDIOCTL_SAVE_HOSTNAME=`/usr/bin/hostname` +AUDIOCTL_SAVE_DEVICE="" +AUDIOCTL_SAVE_DIR="$HOME/.audioctl" +AUDIOCTL_DEVICE_OWNER=`/usr/bin/stat -L /dev/audio -c %U` + +# Only set audio settings if logindevperm has set the owner of the audio +# device to this user. +# +if test "x$USER" = "x$AUDIOCTL_DEVICE_OWNER" ; then + if test -x "/usr/bin/audioctl" ; then + AUDIOCTL_SAVE_DEVICE=`/usr/bin/audioctl show-device | /usr/bin/awk '/^ *Name /{ print $3; }'` + fi + + if test -n "$AUDIOCTL_SAVE_HOSTNAME" -a -n "$AUDIOCTL_SAVE_DEVICE"; then + AUDIOCTL_SAVE_FILE="$AUDIOCTL_SAVE_DIR/audioctl-$AUDIOCTL_SAVE_HOSTNAME-$AUDIOCTL_SAVE_DEVICE" + if test -f "$AUDIOCTL_SAVE_FILE" ; then + /usr/bin/audioctl load-controls $AUDIOCTL_SAVE_FILE + fi + fi +fi + zenity=`gdmwhich zenity` # Note: ~/.xsession-errors is now done in the daemon so that it --- gdm-2.30.0/data/PostSession.in-orig 2010-04-07 15:11:36.882431156 -0500 +++ gdm-2.30.0/data/PostSession.in 2010-04-07 15:13:18.268798760 -0500 @@ -1,4 +1,31 @@ #!/bin/sh PATH="@SCRIPT_PATH@" +AUDIOCTL_SAVE_HOSTNAME=`/usr/bin/hostname` +AUDIOCTL_SAVE_DIR="$HOME/.audioctl" +AUDIOCTL_SAVE_DEVICE="" +AUDIOCTL_DEVICE_OWNER=`/usr/bin/stat -L /dev/audio -c %U` + +# Only set audio settings if logindevperm has set the owner of the audio device +# to this user. +# +if test "x$USER" = "x$AUDIOCTL_DEVICE_OWNER" ; then + if test -x "/usr/bin/audioctl" ; then + AUDIOCTL_SAVE_DEVICE=`/usr/bin/audioctl show-device | /usr/bin/awk '/^ *Name /{ print $3; }'` + fi + + if test -n "$AUDIOCTL_SAVE_HOSTNAME" -a -n "$AUDIOCTL_SAVE_DEVICE"; then + if test ! -d "$AUDIOCTL_SAVE_DIR" ; then + /usr/bin/su $USER -c "/usr/bin/mkdir $AUDIOCTL_SAVE_DIR" + /usr/bin/chmod 700 $AUDIOCTL_SAVE_DIR + fi + + if test -d "$AUDIOCTL_SAVE_DIR" ; then + AUDIOCTL_SAVE_FILE="$AUDIOCTL_SAVE_DIR/audioctl-$AUDIOCTL_SAVE_HOSTNAME-$AUDIOCTL_SAVE_DEVICE" + /usr/bin/su $USER -c "/usr/bin/audioctl save-controls -f $AUDIOCTL_SAVE_FILE" + /usr/bin/chmod 600 $AUDIOCTL_SAVE_FILE + fi + fi +fi + exit 0 --Boundary_(ID_rq9b5Nr1YBYlVXaByBUVkA)-- From mike.oliver@oracle.com Wed Apr 7 19:57:28 2010 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 o382vSnb028957 for ; Wed, 7 Apr 2010 19:57:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o382vR9A035923; Wed, 7 Apr 2010 20:57:28 -0600 (MDT) 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 <0L0J00709EVR9U00@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Apr 2010 19:57:27 -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 <0L0J0022HEVRVT30@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Apr 2010 19:57:27 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o382vR5w019370; Thu, 08 Apr 2010 02:57:27 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o37D0m8p024448; Thu, 08 Apr 2010 02:57:23 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 144771341270695421; Wed, 07 Apr 2010 19:57:01 -0700 Received: from [10.6.102.104] (/10.6.102.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 19:57:00 -0700 Date: Wed, 07 Apr 2010 19:56:59 -0700 From: Mike Oliver Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBCED51.4070904@oracle.com> To: Brian Cameron Cc: "Garrett D'Amore" , PSARC-ext , Desktop Discuss Message-id: <4BBD45FB.40000@oracle.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-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BBD4614.001A:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> <4BBC9E3E.9000706@oracle.com> <4BBCED51.4070904@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.9.1.9) Gecko/20100318 Thunderbird/3.0.4 Status: RO Content-Length: 5444 On 04/07/10 13:38, Brian Cameron wrote: > > Garrett/Mike/Albert: > > I have attached an updated 1-pager and also updated the 1-pager in the > case directory. I have also attached a new patch which implements the > following changes for review: This resolves my concerns about processes running as root inadvertently doing bad things or being tricked into doing bad things. It's strange that the Xsession logic respects $AUDIODEV but the PostSession logic does not. That seems unlikely to produce the correct results if $AUDIODEV is ever set to something other than /dev/audio. Of course it's not easy to get hold of the session's $AUDIODEV in the PostSession context. You could do something like iterate over all of the stored audio setting files for this machine, but I wonder whether this is just more trouble than it's worth for the intended use case and you might reasonably just wire both scripts to operate on /dev/audio. (Subject to the check that that device is owned by this session's user, of course.) I don't feel strongly either way; my main concern was the running-as-root issue, and that's been addressed. Mike. -- mike.oliver@sun.com > 1) In the PostSession script the calls to mkdir and > "audioctl save-controls" are now called with > "/usr/binsu - $USER -c (cmd)" so that the commands which create > directories and files are run as the user. > 2) The code to load the audio settings is now done in the > /etc/gdm/Xsession script after the user's $HOME/.profile is sourced > to ensure that any $AUDIODEV settings are honored on login. > 3) The PostSession script and the Xsession script now call > "/usr/bin/stat -L /dev/audio -c %U" to find out the owner of > the audio device, and will only load or save the data if the > user is actually the owner of the device. This ensures that > only the user who actually has access to the device is modifying > the audio device settings. > 4) Now, as suggested by Albert, the command to get the device is: > > /usr/bin/audioctl show-device | /usr/bin/awk '/^ *Name /{ print $3; }' > > Rather than using grep and sed, so that is a bit simpler. > > I believe this should resolve all the issues raised about this change. > > If a contract is needed to use "audioctl show-device" as described in > this case, then that is okay with me. Yes, this change only needs to > access the are "Device" value, which Garrett indicates should be > stable. > > Brian > > > On 04/ 7/10 10:01 AM, Garrett D'Amore wrote: >> Mike, you raise good issues. I was not aware of the environment which >> PreSession and PostSession took place. I'd like these issues resolved, >> and am withdrawing my +1 until they are properly satisfied. >> >> As far as the output from audioctl show-device goes, we can handle that >> in one of two ways: >> >> 1) add a contract for the interfaces use. I can arrange for my mgmt to >> sign off on it. >> >> 2) increase the commitment level for just that subcommand. I'd be ok >> with raising it to Uncommitted. >> >> Actually, looking at the output, I think they are just using the Device: >> field from the command, which is simple and parseable enough that I'm >> willing to agree that at least *that* portion of it will never change. >> Its the other results that (HW Info, etc.) that are potentially subject >> to change. >> >> - Garrett >> >> On 04/ 7/10 01:26 AM, Mike Oliver wrote: >>> On 4/6/2010 7:56 PM, Brian Cameron wrote: >>>> >>>> I have submitted the following case as PSARC 2010/116 with a timeout >>>> next Wednesday, April 14th. >>>> >>>> This is a pretty trivial interface change, so I am not expecting it >>>> will require much review. I worked out the details with Garrett >>>> D'Amore, and he already reviewed the one-pager and thought it was ready >>>> to submit. >>> >>> You're proposing to modify the Default PreSession and PostSession >>> scripts, >>> right? Not a display-specific script? >>> >>> PreSession and PostSession scripts are executed as root. Do these >>> scripts >>> arrange to execute 'audioctl' as the logged-in (and logging-out) user? I >>> don't see this happening in the patch. >>> >>> Are any measures taken to defend against someone logging in as root (or >>> some other suitably-privileged user) while someone else is using the >>> audio device and therefore clobbering the settings of the user who >>> really owns the audio device? (I know root is a role by default. That >>> doesn't prevent people from converting it back to a normal login >>> account. Obviously this is a bigger issue if these scripts don't run >>> 'audioctl' as $USER.) >>> >>> PSARC 2009/626 says that the device name that is retrieved by >>> 'audioctl show-device' is sensitive to $AUDIODEV, but PostSession (and >>> probably PreSession) has no knowledge of what $AUDIODEV was set to in >>> the user's session. Is it fair to say that this case will only attempt >>> to save and restore the settings of the default audio device, which is >>> not necessarily the device that the user session will use? >>> >>> The 'audioctl show-device' output consumed by this case was declared as >>> "Not An Interface" in PSARC 2009/626. Has the Stability of that output >>> been changed since then? >>> >>> Does GDM guarantee to set $HOME appropriately for these scripts? I know >>> it sets $USER, I can't find anything that guarantees $HOME. >>> >>> Code review nit: using both 'grep' and 'sed' in a single pipeline is >>> rarely necessary. >>> >>> Mike. >> > From garrett.damore@oracle.com Wed Apr 7 21:00:56 2010 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 o3840unH029987 for ; Wed, 7 Apr 2010 21:00:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3840s8A027354; Wed, 7 Apr 2010 21:00:56 -0700 (PDT) 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 <0L0J00B15HTJUX00@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Apr 2010 21:00:55 -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 <0L0J002JOHTJVR60@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Apr 2010 21:00:55 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3840sgg007760; Thu, 08 Apr 2010 04:00:55 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o383fAGJ006149; Thu, 08 Apr 2010 04:00:43 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 156336081270699242; Wed, 07 Apr 2010 21:00:42 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 21:00:42 -0700 Date: Wed, 07 Apr 2010 21:00:40 -0700 From: "Garrett D'Amore" Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBD45FB.40000@oracle.com> To: Mike Oliver Cc: Brian Cameron , PSARC-ext , Desktop Discuss Message-id: <4BBD54E8.9020002@oracle.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-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BBD54EB.00E5:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> <4BBC9E3E.9000706@oracle.com> <4BBCED51.4070904@oracle.com> <4BBD45FB.40000@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1408 On 04/ 7/10 07:56 PM, Mike Oliver wrote: > On 04/07/10 13:38, Brian Cameron wrote: >> >> Garrett/Mike/Albert: >> >> I have attached an updated 1-pager and also updated the 1-pager in the >> case directory. I have also attached a new patch which implements the >> following changes for review: > > This resolves my concerns about processes running as root inadvertently > doing bad things or being tricked into doing bad things. > > It's strange that the Xsession logic respects $AUDIODEV but the > PostSession logic does not. That seems unlikely to produce the correct > results if $AUDIODEV is ever set to something other than /dev/audio. Of > course it's not easy to get hold of the session's $AUDIODEV in the > PostSession context. You could do something like iterate over all of > the stored audio setting files for this machine, but I wonder whether > this is just more trouble than it's worth for the intended use case and > you might reasonably just wire both scripts to operate on /dev/audio. > (Subject to the check that that device is owned by this session's user, > of course.) I don't feel strongly either way; my main concern was the > running-as-root issue, and that's been addressed. > > Mike. The better solution long term, involves the use of device allocation framework. For that framework, we can always do the "right" thing since it can operate with user context. - Garrett From Darren.Moffat@oracle.com Thu Apr 8 02:12:38 2010 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 o389CcWX022393 for ; Thu, 8 Apr 2010 02:12:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o389CbTZ040469; Thu, 8 Apr 2010 03:12:37 -0600 (MDT) 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 <0L0J00907W91HX00@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Apr 2010 02:12:37 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0J006TPW90ED30@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Apr 2010 02:12:36 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o389CZ0h004693; Thu, 08 Apr 2010 09:12:36 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o385wF9h007898; Thu, 08 Apr 2010 09:11:47 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 157031031270717838; Thu, 08 Apr 2010 02:10:38 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Apr 2010 02:10:38 -0700 Date: Thu, 08 Apr 2010 10:10:34 +0100 From: Darren J Moffat Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: To: Albert Lee Cc: Brian Cameron , Mike Oliver , PSARC-ext , Desktop Discuss , Brian Cameron Message-id: <4BBD9D8A.8090605@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BBD9DD3.01A5:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> <4BBC9EE8.10006@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2007 On 07/04/2010 18:39, Albert Lee wrote: >> The PreSession script could check the ownership of /dev/audio and only >> call "audioctl load-controls" if /dev/audio is already owned by the >> user. It is a bit of a drag to follow all the /dev/audio symlinks, >> but it would be smarter. >> > > Something that may have to be addressed eventually is dynamic switching > between multiple X sessions ("fast user switching"). Maybe a note should be > made that the design here will have to be revisited if this is ever > supported. That would be more relevant to the currently running case PSARC 2010/119 "Console User" assignment, logindevperm and virtual console update. Since that case actually ensures that with multiple X sessions only the first (ie :0.0 display) has access to the audio device anyway. If the intent is to allow "switching" of the audio devices then both this case and PSARC/2010/119 need to coordinate and both probably need updated specs. However I don't believe that is the intent because taking away the audio (or other logindevperm assigned devices) on "fast user switching" could actually cause applications currently running to fail. > One policy assumption you could make is that users will want the mixer > preferences for every device rather than just the primary to be remembered > if AUDIODEV isn't set - in that case 'audioctl list-device' could be used. > This would be the least surprising behaviour if it becomes possible to > dynamically change the primary audio device in the future. I agree this is a very good point. This is particularly important when there is "builtin" audio and USB attached audio as well, especially since having the "wrong" volume on USB attached headset could actually be damaging to ones ears. Having said that, this case even if it only does $AUDIODEV is still better than nothing since I suspect (but have no evidence) that most systems (that don't have Sun Ray DTU's attached) only have one audio device. -- Darren J Moffat From garrett.damore@oracle.com Thu Apr 8 06:15:03 2010 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 o38DF3vj026992 for ; Thu, 8 Apr 2010 06:15:03 -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.4) with ESMTP id o38DF2cX035171; Thu, 8 Apr 2010 07:15:03 -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 <0L0K00E477H2A600@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Apr 2010 06:15:02 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0K00MCF7GZO360@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Apr 2010 06:14:59 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o38DExl6026451; Thu, 08 Apr 2010 13:14:59 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o38BX1JJ010520; Thu, 08 Apr 2010 13:14:44 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 145997731270732471; Thu, 08 Apr 2010 06:14:31 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Apr 2010 06:14:30 -0700 Date: Thu, 08 Apr 2010 06:14:29 -0700 From: "Garrett D'Amore" Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBD9D8A.8090605@Oracle.COM> To: Darren J Moffat Cc: Albert Lee , Brian Cameron , Mike Oliver , PSARC-ext , Desktop Discuss , Brian Cameron Message-id: <4BBDD6B5.9010704@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BBDD6C5.005E:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> <4BBC9EE8.10006@oracle.com> <4BBD9D8A.8090605@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 3202 On 04/ 8/10 02:10 AM, Darren J Moffat wrote: > On 07/04/2010 18:39, Albert Lee wrote: >>> The PreSession script could check the ownership of /dev/audio and only >>> call "audioctl load-controls" if /dev/audio is already owned by the >>> user. It is a bit of a drag to follow all the /dev/audio symlinks, >>> but it would be smarter. >>> >> >> Something that may have to be addressed eventually is dynamic switching >> between multiple X sessions ("fast user switching"). Maybe a note >> should be >> made that the design here will have to be revisited if this is ever >> supported. > > That would be more relevant to the currently running case PSARC > 2010/119 "Console User" assignment, logindevperm and virtual console > update. Since that case actually ensures that with multiple X sessions > only the first (ie :0.0 display) has access to the audio device > anyway. If the intent is to allow "switching" of the audio devices > then both this case and PSARC/2010/119 need to coordinate and both > probably need updated specs. However I don't believe that is the > intent because taking away the audio (or other logindevperm assigned > devices) on "fast user switching" could actually cause applications > currently running to fail. Oh wow. I'm working on something that could be a fix for that. Basically, we can switch the plumbing *underneath* the application pretty easily now, and direct the other session to a "sink". We could also provide mixing of all applications if that is more desirable. I think we ought to have a conference call to discuss this in more detail... there are multiple options here and I'd really like to try to tackle this correctly. > >> One policy assumption you could make is that users will want the mixer >> preferences for every device rather than just the primary to be >> remembered >> if AUDIODEV isn't set - in that case 'audioctl list-device' could be >> used. >> This would be the least surprising behaviour if it becomes possible to >> dynamically change the primary audio device in the future. > > I agree this is a very good point. This is particularly important > when there is "builtin" audio and USB attached audio as well, > especially since having the "wrong" volume on USB attached headset > could actually be damaging to ones ears. > > Having said that, this case even if it only does $AUDIODEV is still > better than nothing since I suspect (but have no evidence) that most > systems (that don't have Sun Ray DTU's attached) only have one audio > device. Most, yes. All, no. However, in the future, /dev/audio will always be the most appropriate desktop audio device. We'll use hotplugging underneath a virtual device. But, the save/restore of settings for individual devices won't be appropriate for that. Actually, as I sit here thinking about this, I think the save and restore of audio settings for audio devices should apply to *all* audio devices for the system -- or rather all audio devices that the user is being granted access to (which is usually just all of them, but I think other options exist under device allocation.) We should have a chat to talk about this further. - Garrett From Darren.Moffat@oracle.com Thu Apr 8 11:43:35 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o38IhYr2001718 for ; Thu, 8 Apr 2010 11:43:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o38IhYRo005020; Thu, 8 Apr 2010 13:43:34 -0500 (CDT) 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 <0L0K00J01MOM7N00@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Apr 2010 11:43:34 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0K00EL2MOLL360@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Apr 2010 11:43:33 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o38IhX8U018713; Thu, 08 Apr 2010 18:43:33 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o38Grfgt013169; Thu, 08 Apr 2010 18:43:26 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 158842281270752190; Thu, 08 Apr 2010 11:43:10 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Apr 2010 11:43:09 -0700 Date: Thu, 08 Apr 2010 19:43:06 +0100 From: Darren J Moffat Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBDD6B5.9010704@oracle.com> To: "Garrett D'Amore" Cc: Albert Lee , Brian Cameron , Mike Oliver , PSARC-ext , Desktop Discuss , Brian Cameron Message-id: <4BBE23BA.1060906@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BBE23CF.004A:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> <4BBC9EE8.10006@oracle.com> <4BBD9D8A.8090605@Oracle.COM> <4BBDD6B5.9010704@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2037 On 08/04/2010 14:14, Garrett D'Amore wrote: > On 04/ 8/10 02:10 AM, Darren J Moffat wrote: >> On 07/04/2010 18:39, Albert Lee wrote: >>>> The PreSession script could check the ownership of /dev/audio and only >>>> call "audioctl load-controls" if /dev/audio is already owned by the >>>> user. It is a bit of a drag to follow all the /dev/audio symlinks, >>>> but it would be smarter. >>>> >>> >>> Something that may have to be addressed eventually is dynamic switching >>> between multiple X sessions ("fast user switching"). Maybe a note >>> should be >>> made that the design here will have to be revisited if this is ever >>> supported. >> >> That would be more relevant to the currently running case PSARC >> 2010/119 "Console User" assignment, logindevperm and virtual console >> update. Since that case actually ensures that with multiple X sessions >> only the first (ie :0.0 display) has access to the audio device >> anyway. If the intent is to allow "switching" of the audio devices >> then both this case and PSARC/2010/119 need to coordinate and both >> probably need updated specs. However I don't believe that is the >> intent because taking away the audio (or other logindevperm assigned >> devices) on "fast user switching" could actually cause applications >> currently running to fail. > > Oh wow. > > I'm working on something that could be a fix for that. Basically, we can > switch the plumbing *underneath* the application pretty easily now, and > direct the other session to a "sink". We could also provide mixing of > all applications if that is more desirable. > > I think we ought to have a conference call to discuss this in more > detail... there are multiple options here and I'd really like to try to > tackle this correctly. Audio is only one part of the picture though. What about all the other usb attached devices that logindevperm will be switching owner of: disks, video, ugen etc. What will do you about the webcam that is recording stuff ? Or the disks that are mounted ? -- Darren J Moffat From brian.cameron@oracle.com Thu Apr 8 13:25:34 2010 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 o38KPY6x003252 for ; Thu, 8 Apr 2010 13:25:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o38KPXZW058263; Thu, 8 Apr 2010 14:25:34 -0600 (MDT) 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 <0L0K00203REL7800@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Apr 2010 13:25:33 -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 <0L0K00EE2RELL0E0@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Apr 2010 13:25:33 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o38KPWPX012060; Thu, 08 Apr 2010 20:25:32 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o38DDvv4010465; Thu, 08 Apr 2010 20:25:27 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 159184241270758284; Thu, 08 Apr 2010 13:24:44 -0700 Received: from [129.150.13.116] (/129.150.13.116) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Apr 2010 13:24:43 -0700 Date: Thu, 08 Apr 2010 15:24:39 -0500 From: Brian Cameron Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBD45FB.40000@oracle.com> To: Mike Oliver Cc: Brian Cameron , "Garrett D'Amore" , PSARC-ext , Desktop Discuss Message-id: <4BBE3B87.7040008@oracle.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-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BBE3BB8.004E:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> <4BBC9E3E.9000706@oracle.com> <4BBCED51.4070904@oracle.com> <4BBD45FB.40000@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Thunderbird/3.0.3 Status: RO Content-Length: 1605 Mike: > This resolves my concerns about processes running as root inadvertently > doing bad things or being tricked into doing bad things. Good, thanks. > It's strange that the Xsession logic respects $AUDIODEV but the > PostSession logic does not. That seems unlikely to produce the correct > results if $AUDIODEV is ever set to something other than /dev/audio. Of > course it's not easy to get hold of the session's $AUDIODEV in the > PostSession context. That is true. I can't think of any straightforward way to address this. That said, users who are using such alternative interfaces could create a $HOME/.audioctl/audioctl-(host)-(device) file by hand and have it loaded on subsequent logins. So loading the file in the Xsession script may be of some value to users who want to create the file by hand. > You could do something like iterate over all of > the stored audio setting files for this machine, but I wonder whether > this is just more trouble than it's worth for the intended use case and > you might reasonably just wire both scripts to operate on /dev/audio. > (Subject to the check that that device is owned by this session's user, > of course.) I don't feel strongly either way; my main concern was the > running-as-root issue, and that's been addressed. This is really intended to be a workaround for the common-use case. Many users complain that their audio settings are not preserved well on reboot. While this solution is not perfect and does not work well if users have multiple audio devices, I think it will provide reasonable temporary relief for most users. Brian From brian.cameron@oracle.com Thu Apr 8 13:30:13 2010 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 o38KUDiP003296 for ; Thu, 8 Apr 2010 13:30:13 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o38KUBAR002309; Thu, 8 Apr 2010 13:30:12 -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 <0L0K0070TRMC4A00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Apr 2010 13:30:12 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0K00AYGRMAIO50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Apr 2010 13:30:10 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o38KUAnM029896; Thu, 08 Apr 2010 20:30:10 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o38H2gud014839; Thu, 08 Apr 2010 20:29:42 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 159201851270758512; Thu, 08 Apr 2010 13:28:32 -0700 Received: from [129.150.13.116] (/129.150.13.116) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Apr 2010 13:28:32 -0700 Date: Thu, 08 Apr 2010 15:28:29 -0500 From: Brian Cameron Subject: Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBD9D8A.8090605@Oracle.COM> To: Darren J Moffat Cc: Albert Lee , Mike Oliver , PSARC-ext , Desktop Discuss , Brian Cameron Message-id: <4BBE3C6D.4090705@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BBE3CB7.0140:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> <4BBC41B5.9020702@oracle.com> <4BBC9EE8.10006@oracle.com> <4BBD9D8A.8090605@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Thunderbird/3.0.3 Status: RO Content-Length: 2159 Darren: > That would be more relevant to the currently running case PSARC 2010/119 > "Console User" assignment, logindevperm and virtual console update. > Since that case actually ensures that with multiple X sessions only the > first (ie :0.0 display) has access to the audio device anyway. If the > intent is to allow "switching" of the audio devices then both this case > and PSARC/2010/119 need to coordinate and both probably need updated > specs. However I don't believe that is the intent because taking away > the audio (or other logindevperm assigned devices) on "fast user > switching" could actually cause applications currently running to fail. It would be nicer if audio were virtualized so that each running VT could have their own separate audio device access. Then, when you switch to a different VT, the previous VT could just reassign the audio device to /dev/null until you switch back or something. >> One policy assumption you could make is that users will want the mixer >> preferences for every device rather than just the primary to be >> remembered >> if AUDIODEV isn't set - in that case 'audioctl list-device' could be >> used. >> This would be the least surprising behaviour if it becomes possible to >> dynamically change the primary audio device in the future. > > I agree this is a very good point. This is particularly important when > there is "builtin" audio and USB attached audio as well, especially > since having the "wrong" volume on USB attached headset could actually > be damaging to ones ears. > > Having said that, this case even if it only does $AUDIODEV is still > better than nothing since I suspect (but have no evidence) that most > systems (that don't have Sun Ray DTU's attached) only have one audio > device. Note that Sun Ray does not support OSS anyway, so there is no plans to support Sun Ray with this case until Sun Ray is migrated to use OSS instead. If there is any work needed to improve the way this works to support Sun Ray, I think it should be done in coordination with Sun Ray migrating to OSS, not now. Sun Ray is, I think, the primary use-case where AUDIODEV tends to be used. Brian From brian.cameron@oracle.com Thu Apr 22 20:11:18 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3N3BHqp002402 for ; Thu, 22 Apr 2010 20:11:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3N3BHca001521; Thu, 22 Apr 2010 22:11:17 -0500 (CDT) 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 <0L1B00N177IT2400@brm-avmta-1.central.sun.com>; Thu, 22 Apr 2010 21:11:17 -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 <0L1B00I7D7ITX720@brm-avmta-1.central.sun.com>; Thu, 22 Apr 2010 21:11:17 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3N3BG8O016493; Fri, 23 Apr 2010 03:11:16 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3N2aPXv002403; Fri, 23 Apr 2010 03:11:14 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 201359821271992164; Thu, 22 Apr 2010 20:09:24 -0700 Received: from [129.150.12.108] (/129.150.12.108) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Apr 2010 20:09:23 -0700 Date: Thu, 22 Apr 2010 22:09:19 -0500 From: Brian Cameron Subject: Re: GDM Integration With audioctl [PSARC/2010/116] In-reply-to: <4BBBF44B.7020200@sun.com> To: Brian Cameron Cc: PSARC-ext , Desktop Discuss Message-id: <4BD10F5F.8020802@oracle.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-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BD10FD2.0117:SCFMA4539814,ss=1,fgs=0 References: <4BBBF44B.7020200@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Thunderbird/3.0.3 Status: RO Content-Length: 5418 This case was approved at last Wednesday's PSARC meeting, so I marked the IAM file as "closed approved fast-track 04/21/2010". Brian On 04/ 6/10 09:56 PM, Brian Cameron wrote: > > I have submitted the following case as PSARC 2010/116 with a timeout > next Wednesday, April 14th. > > This is a pretty trivial interface change, so I am not expecting it > will require much review. I worked out the details with Garrett > D'Amore, and he already reviewed the one-pager and thought it was ready > to submit. > > I have also attached the patch to the GDM PreSession & PostSession > script which implements the interface change described in this > one-pager in case anybody wants to review it as well. > > Thanks, > > Brian > > --- > > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2007 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: > > GDM Integration With audioctl > > 1.2. Name of Document Author/Supplier: > > Brian Cameron > > 1.3. Date of This Document: > > March 06, 2010 > > 1.3.1. Date this project was conceived: > > March 06, 2010 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > > 1.4.1. The PAC or CPT you expect to review your project: > > System PAC > > 1.4.2. The ARC(s) you expect to review your project: > > PSARC > > 1.4.3. The Director/VP who is "Sponsoring" this project: > > robert.odea@sun.com > > 1.4.4. The name of your business unit: > > Solaris Platform Engineering > > 1.5. Email Aliases: > > 1.5.1. Responsible Manager: > > leo.binchy@sun.com > > 1.5.2. Responsible Engineer: > > brian.cameron@sun.com > > 1.5.3. Marketing Manager: > > glynn.foster@sun.com > > 1.5.4. Interest List: > > desktop-discuss@opensolaris.org > > 2. Project Summary > > 2.1 Project Description: > > This ARC case addresses bugster CR #6606096 by providing a > mechanism for the user's audio settings to be saved on logout and > re-loaded on login. This ensures that the audio settings are > returned to the user's preferred values on reboot or when one user > logs out and another user logs in. > > There has been some discussion with the Device Allocation team about > solving this problem at a lower level so that audio preferences are > saved and loaded when the audio device is allocated or > deallocated. Until a better low-level solution exists, this case > provides users with temporary relief. This is needed since many > users complain that their audio settings are lost and returned to > the default system values each time they reboot their machine. > However, this integration will likely be removed if and when a more > general solution is available. > > 4. Technical Description: > > 4.1. Details: > > To save the user's audio settings, the GDM PostSession script > is modified to save the user's audio settings on logout. > > The user's audio settings values are stored in the > $HOME/.audioctl directory. The PostSession script creates > this directory if it is not present and ensures it has 700 > permissions and is owned by the user and associated with the > user's primary group. > > The PostSession script then saves the user's audio settings by > calling the /usr/bin/audioctl program as follows: > > /usr/bin/audioctrl save-controls -f > $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME > > The HOSTNAME value is obtained by calling /usr/bin/hostname and > the DEVICENAME value is obtained by calling the following > command: > > /usr/bin/audioctl show-device | grep Name | sed 's/.*= *//g' > > The resulting $HOME/.audioctl/audioctl-$HOMENAME-$DEVICENAME > file is created with 600 permissions and also is owned by the > user and associated with the user's primary group. > > This ensures that the audio default settings are saved uniquely > per-machine and per-device for each user. Thus, each user who > shares their $HOME directory across multiple systems will have > discrete settings for each machine and device that they use. > > The GDM PreSession script loads the settings when the user > next logs in by calling this command, constructing the > filename in the same manner as described above: > > /usr/bin/audioctl load-controls > $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME > > 4.2. Bug/RFE Number(s): > > CR #6606096 > > 4.5. Interfaces: > > Exported Interface > > Interface Classification Comments > ------------------------- -------------- ---------------------- > $HOME/.audioctl/audioctl-$HOSTNAME-$DEVICENAME > Volatile User's audio > settings > > Imported Interface > > Interface Classification ARC case Comment > -------- --------------- ---------- ---------------- > /usr/bin/audioctl Committed PSARC 2009/626 > > 4.6. Doc Impact: > > None. > > 4.7. Admin/Config Impact: > > None. > > 4.8. HA Impact: > > None. > > 4.9. I18N/L10N Impact: > > None. This change adds no messages needing translation. > > 4.10. Packaging & Delivery: > > Included with GDM. > > 4.11. Security Impact: > > File system permissions and ownership are used to ensure that > each user's configuration files can not be accessed or > modified by other users. > > 4.12. Dependencies: > > This solution only works on systems that support OSS. For > example, it will not work in Sun Ray environments until they > support OSS or on systems that do not have OSS audio driver > support. > > 5. Reference Documents: > > None. > > > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org