Mark/Tomas/Miles: 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.
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. It seems that it would cause obvious problems if the GDM daemon simply changed the ownership/permissions of the audio device files when starting the GUI login screen. What if a second user tries to log in via XDMCP after another user has already logged in, has ownership of the audio device, and is using it? We probably don't want the second login screen to steal the audio device away from the first user. Also, making the file have "all user" read/write permissions is not desirable since it would make a denial-of-service attack simple, where a second user could take over the audio device. ACL's seemed a good solution since it leaves the overall ownership and permissions of the device the same, but just adds the gdm user as having permission to access the device as needed. Is there any way to get this same sort of behavior when using ZFS. If not, can people recommend a better way to manage audio device permisisons from the login screen? I know on some Linux distros, they make the audio device owned by the "audio" group and ensure that the "gdm" user is in the audio group. Perhaps we should use a similar approach on Solaris if ACL isn't a practical solution for all file systems. Remember that the need to have access to the audio device from the login screen is only used to support text-to-speech so that users with certain accessibility needs can navigate the login screen. In other words, it is a feature that only a small percentage of users really need, but a feature that makes the desktop completely unusable for them if it is not present. Thoughts? Thanks again for all the help, Brian Mark Shellenbaum wrote: > >> However, I notice that when using ZFS on Indiana the above commands fail >> with the following error: >> >> File system doesn't support aclent_t style ACL's. >> See acl(5) for more information on ACL styles support by Solaris. >> >> What is the appropriate command to use with ZFS? > > You can use pathconf() with _PC_ACL_ENABLED to determine what flavor of > ACL the file system supports. > > check out these links. > > http://docs.sun.com/app/docs/doc/816-5167/fpathconf-2?a=view > http://blogs.sun.com/alvaro/entry/detecting_the_acl_type_you > > The example in the blog isn't quite correct. The returned value is a > bit mask, and it is possible for a file system to support multiple ACL > flavors. > > Here is an example of pathconf() as used in acl_strip(3sec) > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libsec/common/aclutils.c#390 > > > > > -Mark _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
