Mark:
> You could call acl(2) directly, but you would have to construct a
> complete ACL to set. It would be easier to use acl_get() and acl_set()
> which understand the various ACL flavors and will call the syscall with
> correct ACL flavor arguments.
>
> Unfortunately, what you are wanting
Mark & Others:
> I think you may have misunderstood what people were suggesting. They
> weren't suggesting changing the mode of the file, but using chmod(1M) to
> add/modify ZFS ACLs on the device file.
>
> chmod A+user:gdm:rwx:allow
>
> See chmod(1M) or the zfs admin guide for ZFS ACL exam
Nicolas:
> On Mon, Dec 08, 2008 at 03:27:49PM -0600, Brian Cameron wrote:
>> 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 ac
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
>> d
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 owne
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
I am the maintainer of GDM, and I am noticing that GDM has a problem when
running on a ZFS filesystem, as with Indiana.
When GDM (the GNOME Display Manager) starts the login GUI, it runs the
following commands on Solaris:
/usr/bin/setfacl -m user:gdm:rwx,mask:rwx /dev/audio
/usr/bin/setfac
