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