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