On Mon, Dec 08, 2008 at 02:22:01PM -0600, Brian Cameron wrote: > >That said, I don't see why di_devperm_login() couldn't stomp all over > >the ACL too. So you'll need to make sure that di_devperm_login() > >doesn't stomp over the ACL, which will probably mean running an ARC case > >and updating the logindevperm(4) manpage. > > I agree that the solution of GDM messing with ACL's is not an ideal > solution. No matter how we resolve this problem, I think a scenario > could be imagined where the audio would not be managed as expected. > This is because if multiple users are competing for the same audio > device, then a user with a11y text-to-speech issues can easily find > themselves in a situation where they can't use audio in their session > because another user has already acquired it. Even if GDM allows you > to log in with text-to-speech, this is not really useful if you can > not use the audio device once you have logged into your session.
How would that happen? Aren't we trying hard to associate individual devices with individual seats? Or is there some issue where a login on a VT console could steal devices from a login on a graphical console? (I could see how that could happen, but that seems like a serious bug to me: text logins shouldn't need to acquire /dev/audio and friends, unless specifically configured to do so. But in any case, it doesn't matter much since in the VT case there's a single physical seat, so the user would have to be purposefully trying to excercise a GDM vs login(1) race.) > Note this is not really an issue with Sun Ray since each Sun Ray > device has their own audio pseudo-device and users are not competing > for the same device. These logindevperm issues is only a concern for users > logging in via the console (with VT or otherwise). Right. I find it odd that we use a different device allocation mechanism for console vs. SunRay logins, but that's a different story. > Really, the purpose of using ACL's is to give GDM access to the audio > device in the normal use-case where a user with accessibility needs > is not competing with other users for the audio device. It is a nice > technique to use since it doesn't confuse logindevperm by changing the > actual ownership/permissions of the device files. Because logindevperm isn't resetting the ACL. But how do you prevent another engineer from adding code to do that at some future point? That's what my comment about ARCing this was about. > If we want to try to solve the bigger problem of how text-to-speech > should work when users are competing for the same audio device, then that > is a much bigger problem, I think. I do not think this is a very common No, that's not the problem I care about. The problem I care about is: how to make sure that logindevperm never gets modified to set devices' ACLs in any way that might trample on GDM's ACL entries. > [...] > > The main reason this issue came up is because Indiana uses ZFS, and > the ACL's that GDM use obviously stopped working, and this caused > text-to-speech stopped working when using GDM on Indiana. I mainly needed > help to figure out how to use ACL's with ZFS so GDM can work on Indiana > as well as it does on Nevada. Or perhaps the reason it came up is that GDM was doing something that noone knew it was doing. (I'm not sure, and I don't care which is the case.) Thus the concern about making sure this doesn't come up again. > >Alternatively, can't GDM open the devices it needs before dropping > >privileges? It does run with all [zone] privileges, after all. > > This might be possible, but I do not think it would be easy. Note that > the root-running GDM daemon runs the login GUI as the "gdm" user. But with all [zone] privileges, right? > Then AT programs (such as orca) are launched via a11y interfaces > by the login program (if GDM is configured with a11y turned on). With or without privilege? > Coming up with some mechanism so that the root-running daemon opened > the device and somehow passed this file-handle off to a subprocess running > as a different user seems tricky. Nah, just pass the necessary privileges and let the AT programs drop them after opening the devices. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
