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.


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:

             [email protected]

      1.4.4. The name of your business unit:

             Solaris Platform Engineering

   1.5. Email Aliases:

      1.5.1. Responsible Manager:

             [email protected]

      1.5.2. Responsible Engineer:

             [email protected]

      1.5.3. Marketing Manager:

             [email protected]

      1.5.4. Interest List:

             [email protected]

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.

--- 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
_______________________________________________
opensolaris-arc mailing list
[email protected]

Reply via email to