Nicolas: >> 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.)
Once VT is enabled in the Xserver and GDM, users can start multiple graphical logins with GDM. So, if a user logs into the first graphical login, they get the audio device. Then you can use VT switching in GDM to start up a second graphical login. If this user needs text-to-speech, they are out of luck since they can't access the audio device from their user session regardless if they can log in. At any rate, VT is not yet enabled in the Xserver or GDM, so there really isn't an issue that needs to be addressed until this is integrated and working in Solaris. Console login also does use logindevperm, so you could also have this problem if a user logged into a text console, then started GDM. Though this would be an odd usage of the system. If a user were to do this, they shouldn't be surprised if it doesn't work properly. >> 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. Sun Ray devices don't use logindevperm, since logindevperm is used just for the console. On Sun Ray, each device has their own audio interface as defined by the AUDIODEV environment variable. >> 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. Perhaps I should explain the history of this a bit, just so you understand how the code has evolved. In Solaris 10, GDM used logindevperm to give the gdm user access to the audio device. When the GDM login GUI started up, it called logindevperm interfaces to give the "gdm" user access to the audio device. Then when a user logged in, it would unset the "gdm" user via logindevperm interfaces, and then call logindevperm as the user who is going to log in to give them permission. Likewise when the user logged out, it would unset that user and give the devices back to the gdm user via logindevperm interfaces. This worked fine before VT was introduced into Solaris since only one GDM process could be running on the console at a time. When we started preparing GDM to work with VT, we had to change this. We modified GDM to use ACL's recently because it works in a way that is more compatible with how logindevperm works when VT is being used to support multiple graphical logins. Since GDM is being rewritten, and we plan to integrate the rewritten GDM into Solaris soon, would it be acceptable to ARC this when we integrate the new GDM, or do you think it needs to be ARC'ed more immediately? >> 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. Yes, that makes sense. >>> 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? The login GUI is run with limited privilege. >> 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? Without. The whole point of running the login GUI and AT programs as the "gdm" user is to ensure that if someone where to somehow compromise the GUI programs, they wouldn't get any privilege beyond what the gdm user has. >> 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. I think I would need some help to understand how to solve the problem this way. It might be best to take this off-line and discuss further privately since we aren't really talking about ZFS anymore. That said, I am not sure it is really necessary to invest a lot of energy "fixing" this problem. As I said, the only time you really run into a problem is when graphical login VT support is turned on. For obvious reasons, you would never want to use VT in an environment where you need text-to-speech anyway. It would probably make more sense for users with text-to-speech needs to disable VT than to fix this problem. In other words, if we "fix" this problem, we could make GDM smart enough to always be able to access the audio device so users can log in, even if another user has acquired the audio device, but audio would still be unavailable in the session they would log into, and thus be useless. Note that once VT is enabled logindevperm works on a first-come-first-serve basis. The first user who logs in gets the permissions, and logindevperm will not change the device ownership/permissions again until that user logs out. So logindevperm interfaces would never reset the permissions while a user who has already acquired the devices is logged in. In other words, when VT is not enabled, there is never a realistic opportunity for another process to affect the state of the audio device permissions while the GDM GUI is running. Brian _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
