Nicholas: > On Sun, Dec 07, 2008 at 03:20:01PM -0600, Brian Cameron wrote: >> Thanks for the information. Unfortunately, using chmod/chown does not >> seem a workable solution to me, unless I am missing something. Normally >> logindevperm(4) is used for managing the ownership and permissions of >> device files (like the audio device), and if the GDM daemon just calls >> chown/chmod on the audio device, then it seems this could easily cause >> inconsistencies with logindevperm. > > As Mark replied, chmod(1) isn't just for setting file permissions, but > also for ACL manipulation.
Yes, sorry for being thick, and thanks to everyone for explaining things. I think I understand better now. > 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. 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). 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. 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 use-case, though. GDM has pretty much worked the same way since Solaris 10, and I have never had a user complain about this sort of issue. Though this could perhaps become more of an issue when VT usage becomes more popular. That said, Linux distros have the same problem. 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. > 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. Then AT programs (such as orca) are launched via a11y interfaces by the login program (if GDM is configured with a11y turned on). 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. >> Remember, for example, that multiple users can login into the same >> machine. Perhaps one via the console, and other users via XDMCP or >> other remote methods. VT (Virtual Terminal) will soon integrate >> into Solaris and add yet another way that users can log in. > > VT is in *now* and has been for a few builds. Sort of. VT is in the kernel, but not yet enabled in the Xserver. It also is not turned on via SMF by default. From GDM's perspective, VT isn't really useful if it isn't supported by the Xserver. Thus VT is not supported by GDM currently either. I understand VT will be enabled in the Xserver sometime in the next quarter. Once that is done, then VT will be fully supported on Solaris. Brian _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
