zfs discuss - Dec 2008 - Problem with ZFS and ACL with GDM

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/setfacl -m user:gdm:rwx,mask:rwx /dev/audioctl

It does this because the login GUI programs are run as the "gdm" user,
and in order to support text-to-speech via orca, for users with
accessibility needs, the "gdm" user needs access to the audio device.
We were using setfacl because logindevperm(3) normally manages the
audio device permissions and we only want the "gdm" user to have
access on-the-fly when the GDM GUI is started.

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?  If different commands
are needed based on the file system type, then how can GDM determine which
command to use.  Or is there a better way for GDM to ensure that the
audio devices has the appropriate permissions for the "gdm" user to
support text-to-speech accessibility?

I am not subscribed to this list, so please cc: me in any response.

Thanks,

Brian

On 05 December, 2008 - Brian Cameron sent me these 1,5K bytes:
> 
> 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/setfacl -m user:gdm:rwx,mask:rwx /dev/audioctl
> 
> It does this because the login GUI programs are run as the "gdm"
user,
> and in order to support text-to-speech via orca, for users with
> accessibility needs, the "gdm" user needs access to the audio
device.
> We were using setfacl because logindevperm(3) normally manages the
> audio device permissions and we only want the "gdm" user to have
> access on-the-fly when the GDM GUI is started.
> 
> 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?
chmod
> If different commands are needed based on the file system type, then
> how can GDM determine which command to use.
Do both? :)

/Tomas
-- 
Tomas ?gren, stric at acc.umu.se, http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Ume?
`- Sysadmin at {cs,acc}.umu.se

> 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

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

> 
> 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.
> 
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 <file>

See chmod(1M) or the zfs admin guide for ZFS ACL examples.

> 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
> 
>

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.

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.

Alternatively, can''t GDM open the devices it needs before dropping
privileges?  It does run with all [zone] privileges, after all.
> 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.

Nico
--

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

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
--

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

On Mon, Dec 08, 2008 at 03:27:49PM -0600, Brian Cameron
wrote:
> 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
Ah, right, I''d forgotten this.
> 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.
Well, shouldn''t this mean that /dev/audio should get virtuallized so
that it''s as /dev/null when the console is switched to a different VT,
so only the current VT ever has access to the real /dev/audio?

Is there a shortcomming in VT here?
> 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.
I would be!
> 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
> ...
I didn''t realize that we had A11Y support in S10''s GDM!  I
thought that
was one of the problems with it.  How do you configure A11Y for GDM?  I
would really like to enable sticky keys at the GDM screen.
> >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.
> 
> ...
> 
> The login GUI is run with limited privilege.
Ah, OK.

So methinks there needs to at least be a comment in logindevperm code to
guard against someone causing it to clobber GDM''s ACL entry.  The ARC
might care to know too; ask a member.

Nico
--

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 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.
> 
> Well, shouldn''t this mean that /dev/audio should get virtuallized
so
> that it''s as /dev/null when the console is switched to a different
VT,
> so only the current VT ever has access to the real /dev/audio?
> 
> Is there a shortcomming in VT here?
I guess it depends on how you think VT should work.  My understanding
is that VT works on a first-come-first-serve basis, so the first user
who calls logindevperm interfaces gets permission.  While it might seem
nicer for the last user to get the device, this is much harder to manage.
Making it work the other way would require logindevperm to be enhanced.
I believe this is because logindevperm only has interfaces to indicate
a user has logged in or out, and does not support any way to inform
logindevperm that a user switch has happened.

Also, I think it gets complicated to manage if the first user has
programs running which are using the audio device, or other devices
managed by logindevperm.  How to manage unconnecting them when a VT
switch happens, and then reconnecting them when switching back would
be complicated and probably error-prone.

At any rate, I think it would be a pretty significant enhancement to
the existing interfaces to support this sort of behavior.

If you are interested, you can discuss this further with the VT team
if you want to make suggestions about how this should all work.
Aaron.Zang at Sun.COM is the engineer working on VT, and would be the
right person to talk to.
>> 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.
> 
> I would be!
If you log into the console first, then it calls logindevperm interfaces
first and wins.  Any graphical logins would not get permission, unless (of
course) you logged into the same user as you used when logging into the
console.

At any rate, now that you know, you will not be surprised.  :)
>> 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
>> ...
> 
> I didn''t realize that we had A11Y support in S10''s GDM! 
I thought that
> was one of the problems with it.  How do you configure A11Y for GDM?  I
> would really like to enable sticky keys at the GDM screen.
When I have been talking about to a11y in GDM, I have been referring to the
ability to start AT programs such as orca or GOK.  Xserver a11y features
like sticky keys should "just work" if you enable them via keyboard
shortcuts.  I believe hitting the Shift key five times in a row enables
Sticky Keys.  I am not sure if this keyboard shortcut is available by
default or not in GDM.

You might need to setup your Xserver configuration or the Xserver arguments
used when GDM starts the Xserver in the GDM configuration to make this work.
There is probably also some Xserver interfaces you could use to configure it
to just always be on by default, though I am not sure how to do that.  You
would need to refer to the Xserver documentation.
>> The login GUI is run with limited privilege.
> 
> Ah, OK.
> 
> So methinks there needs to at least be a comment in logindevperm code to
> guard against someone causing it to clobber GDM''s ACL entry.  The
ARC
> might care to know too; ask a member.
Thanks, I overlooked bringing this up to ARC.  I will make sure that the
GDM usage of these interfaces is ARC''ed before VT is enabled in the
Solaris
Xserver and GDM.  This really only becomes something to care about after
that happens.

I do appreciate you helping me to make sure we integrate all of this
properly.

Brian

On Mon, Dec 08, 2008 at 04:46:37PM -0600, Brian Cameron
wrote:
> >Is there a shortcomming in VT here?
> 
> I guess it depends on how you think VT should work.  My understanding
> is that VT works on a first-come-first-serve basis, so the first user
> who calls logindevperm interfaces gets permission.  While it might seem
> nicer for the last user to get the device, this is much harder to manage.
No, I think audio should be virtualized.  The current session should
have access to the real audio hardware, and the others should not be
able to produce sound (though as afar as apps go, they shouldn''t know
the difference).
> Making it work the other way would require logindevperm to be enhanced.
Perhaps.  It will also require virtualizing the audio device.
> Also, I think it gets complicated to manage if the first user has
> programs running which are using the audio device, or other devices
> managed by logindevperm.  How to manage unconnecting them when a VT
> switch happens, and then reconnecting them when switching back would
> be complicated and probably error-prone.
When I switch away from a session where programs are producing sound
what should happen is this: a) those programs continue to operate, b)
but they don''t produce actual sound until I switch back to that VT (and
unlock the screen).
> At any rate, I think it would be a pretty significant enhancement to
> the existing interfaces to support this sort of behavior.
> 
> If you are interested, you can discuss this further with the VT team
> if you want to make suggestions about how this should all work.
> Aaron.Zang at Sun.COM is the engineer working on VT, and would be the
> right person to talk to.
OK, I will!  Thanks for the contact.
> >I didn''t realize that we had A11Y support in S10''s
GDM!  I thought that
> >was one of the problems with it.  How do you configure A11Y for GDM?  I
> >would really like to enable sticky keys at the GDM screen.
> 
> When I have been talking about to a11y in GDM, I have been referring to the
> ability to start AT programs such as orca or GOK.  Xserver a11y features
> like sticky keys should "just work" if you enable them via
keyboard
> shortcuts.  I believe hitting the Shift key five times in a row enables
> Sticky Keys.  I am not sure if this keyboard shortcut is available by
> default or not in GDM.
I''ll try it tonight.
> >So methinks there needs to at least be a comment in logindevperm code
to
> >guard against someone causing it to clobber GDM''s ACL entry. 
The ARC
> >might care to know too; ask a member.
> 
> Thanks, I overlooked bringing this up to ARC.  I will make sure that the
> GDM usage of these interfaces is ARC''ed before VT is enabled in
the Solaris
> Xserver and GDM.  This really only becomes something to care about after
> that happens.
OK, but sending a comment now wouldn''t hurt ("ARC early, ARC
often").

Nico
--

>On Mon, Dec 08, 2008 at 04:46:37PM -0600, Brian Cameron wrote:
>> >Is there a shortcomming in VT here?
>> 
>> I guess it depends on how you think VT should work.  My understanding
>> is that VT works on a first-come-first-serve basis, so the first user
>> who calls logindevperm interfaces gets permission.  While it might seem
>> nicer for the last user to get the device, this is much harder to
manage.
>
>No, I think audio should be virtualized.  The current session should
>have access to the real audio hardware, and the others should not be
>able to produce sound (though as afar as apps go, they shouldn''t
know
>the difference).
I think we talked about this at the time but in the end we made
a vt subsystem which works like others do.

But I agree with you.  It doesn''t necessarily virtualizing /dev/audio,
adding but adding $AUDIODEV to the environment of such a session.
(E.g., /dev/vt/sound/...).

At this time, it seems that the last one to login gets /dev/sound?

>> Making it work the other way would require logindevperm to be enhanced.
>
>Perhaps.  It will also require virtualizing the audio device.
And possibly not, because a simple rule can be used if we give the
virtualized audio a different device node.
>When I switch away from a session where programs are producing sound
>what should happen is this: a) those programs continue to operate, b)
>but they don''t produce actual sound until I switch back to that VT
(and
>unlock the screen).
I''m not sure why the programs should stop; it''s just as valid
to
throw the output away.

Casper

On Tue, Dec 09, 2008 at 09:09:15AM +0100, Casper.Dik at Sun.COM
wrote:
> >When I switch away from a session where programs are producing sound
> >what should happen is this: a) those programs continue to operate, b)
> >but they don''t produce actual sound until I switch back to
that VT (and
> >unlock the screen).
> 
> I''m not sure why the programs should stop; it''s just as
valid to
> throw the output away.
I didn''t mean that they should stop -- they should continue, but their
sound output should be muted.

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 <file>
> 
> See chmod(1M) or the zfs admin guide for ZFS ACL examples.
Thanks for your help.  Now GDM is using the following code to set ACL''s
(spacing slightly modified for readability):

	{
                 int acl_flavor;
                 acl_flavor = pathconf("/dev/audio", _PC_ACL_ENABLED);

                 if (acl_flavor & _ACL_ACLENT_ENABLED) {
                         system ("/usr/bin/setfacl -m user:gdm:rwx,mask:rwx
                                 /dev/audio");
                         system ("/usr/bin/setfacl -m user:gdm:rwx,mask:rwx
                                 /dev/audioctl");
                 } else if (acl_flavor & _ACL_ACE_ENABLED) {
                         system ("/usr/bin/chmod A+user:gdm:rwx:allow
                                 /dev/audio");
                         system ("/usr/bin/chmod A+user:gdm:rwx:allow
                                 /dev/audioctl");
                 }
	}

That works much better, and now GDM text-to-speech works much better on
ZFS filesystems.

However, now I am wondering if it might be better to call acl(2) functions
rather than spawning off new processes via system().  Does setfacl(2), for
exmaple, work with both flavors, or would I need to call different functions
based on the acl_flavor?  I am not very familiar with working with
acl''s, so any help explaining how to modify the above code to use acl
functions rather than calling system would be helpful.

Thanks,

Brian

Brian Cameron wrote:
> 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 <file>
>>
>> See chmod(1M) or the zfs admin guide for ZFS ACL examples.
> 
> Thanks for your help.  Now GDM is using the following code to set
ACL''s
> (spacing slightly modified for readability):
> 
> 	{
>                  int acl_flavor;
>                  acl_flavor = pathconf("/dev/audio",
_PC_ACL_ENABLED);
> 
>                  if (acl_flavor & _ACL_ACLENT_ENABLED) {
>                          system ("/usr/bin/setfacl -m
user:gdm:rwx,mask:rwx
>                                  /dev/audio");
>                          system ("/usr/bin/setfacl -m
user:gdm:rwx,mask:rwx
>                                  /dev/audioctl");
>                  } else if (acl_flavor & _ACL_ACE_ENABLED) {
>                          system ("/usr/bin/chmod A+user:gdm:rwx:allow
>                                  /dev/audio");
>                          system ("/usr/bin/chmod A+user:gdm:rwx:allow
>                                  /dev/audioctl");
>                  }
> 	}
> 
> That works much better, and now GDM text-to-speech works much better on
> ZFS filesystems.
> 
> However, now I am wondering if it might be better to call acl(2) functions
> rather than spawning off new processes via system().  Does setfacl(2), for
> exmaple, work with both flavors, or would I need to call different
functions
> based on the acl_flavor?  I am not very familiar with working with
> acl''s, so any help explaining how to modify the above code to use
acl
> functions rather than calling system would be helpful.
> 
> Thanks,
> 
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 to do is retrieve the ACL, prepend 
an entry and then call acl_set().  There is a private interface in 
libsec called acl_addentries() that can do such a thing, but that 
interface could change and I''m not sure I would recommend using it
since
gdm isn''t in ON.  Also, acl_entries needs the added ACE entries to be
in
raw ace_t format and not the textual representation you are setting with 
chmod(1).  We definately need some better ACL interfaces for this sort 
of thing.

You should probably make sure that you just don''t keep continually 
adding the same entry over and over again to the ACL.  With NFSv4 ACLs 
you can insert the same entry multiple times and if you keep doing it 
long enough you will eventually get an error back when you reach the ACE 
limit on the file.

There is code in libdevinfo called setdevaccess() that will strip off 
all ACEs on a device file via acl_strip(3sec).  The setdevaccess() 
interface is called by di_devperm_login().  Does gdm use that interface?

   -Mark

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 to do is retrieve the ACL, prepend 
> an entry and then call acl_set().  There is a private interface in 
> libsec called acl_addentries() that can do such a thing, but that 
> interface could change and I''m not sure I would recommend using it
since
> gdm isn''t in ON.  Also, acl_entries needs the added ACE entries to
be in
> raw ace_t format and not the textual representation you are setting with 
> chmod(1).  We definately need some better ACL interfaces for this sort 
> of thing.
Hmmm, calling system() is not looking like such a bad solution after all.
> You should probably make sure that you just don''t keep continually
> adding the same entry over and over again to the ACL.  With NFSv4 ACLs 
> you can insert the same entry multiple times and if you keep doing it 
> long enough you will eventually get an error back when you reach the ACE 
> limit on the file.
Note that logindevperm will reset the ownership and permission of the
file each time a user logs in or out.  I guess I was assuming this would
reset the ACL''s as well.  Is this not the case?

At any rate, it wouldn''t hurt to check to see if the ACL is there
already.
Do you have a code example that shows how to do that?
> There is code in libdevinfo called setdevaccess() that will strip off 
> all ACEs on a device file via acl_strip(3sec).  The setdevaccess() 
> interface is called by di_devperm_login().  Does gdm use that interface?
Yes, does this mean that the ACL''s are getting reset anyway each time a
user logs in?  If so, then I don''t think there is a real need to worry
about the ACL list getting too long.  Since logindevperm is only used
for console login, there wouldn''t be any issues (for example) in a
Sun Ray environment where multiple login screens would be showing
and calling the ACL list at the same time.

Brian

>> You should probably make sure that you just don''t keep
continually
>> adding the same entry over and over again to the ACL.  With NFSv4 ACLs 
>> you can insert the same entry multiple times and if you keep doing it 
>> long enough you will eventually get an error back when you reach the 
>> ACE limit on the file.
> 
> Note that logindevperm will reset the ownership and permission of the
> file each time a user logs in or out.  I guess I was assuming this would
> reset the ACL''s as well.  Is this not the case?
> 
Yes, it also changes the owner and group.
> At any rate, it wouldn''t hurt to check to see if the ACL is there
already.
> Do you have a code example that shows how to do that?
> 
Nope, but you should be able to just use access(2) to determine if you 
need to add the ACL entry.
>> There is code in libdevinfo called setdevaccess() that will strip off 
>> all ACEs on a device file via acl_strip(3sec).  The setdevaccess() 
>> interface is called by di_devperm_login().  Does gdm use that
interface?
> 
> Yes, does this mean that the ACL''s are getting reset anyway each
time a
> user logs in?  If so, then I don''t think there is a real need to
worry
> about the ACL list getting too long.  Since logindevperm is only used
> for console login, there wouldn''t be any issues (for example) in a
> Sun Ray environment where multiple login screens would be showing
> and calling the ACL list at the same time.
> 
> Brian
>

Mark Shellenbaum wrote:
>>> You should probably make sure that you just don''t keep
continually
>>> adding the same entry over and over again to the ACL.  With NFSv4
ACLs
>>> you can insert the same entry multiple times and if you keep doing
it
>>> long enough you will eventually get an error back when you reach
the
>>> ACE limit on the file.
>> Note that logindevperm will reset the ownership and permission of the
>> file each time a user logs in or out.  I guess I was assuming this
would
>> reset the ACL''s as well.  Is this not the case?
>>
> 
> Yes, it also changes the owner and group.
> 
>> At any rate, it wouldn''t hurt to check to see if the ACL is
there already.
>> Do you have a code example that shows how to do that?
>>
> 
> Nope, but you should be able to just use access(2) to determine if you 
> need to add the ACL entry.
> 
But that probably won''t work since you won''t be running as
that user yet
and access(2) would be checking off of a privileged cred.

  -Mark

On Thu, Dec 11, 2008 at 04:46:33PM -0700, Mark Shellenbaum
wrote:
> Mark Shellenbaum wrote:
> >>> You should probably make sure that you just don''t
keep continually
> >>> adding the same entry over and over again to the ACL.  With
NFSv4 ACLs
> >>> you can insert the same entry multiple times and if you keep
doing it
> >>> long enough you will eventually get an error back when you
reach the
> >>> ACE limit on the file.
> >> Note that logindevperm will reset the ownership and permission of
the
> >> file each time a user logs in or out.  I guess I was assuming this
would
> >> reset the ACL''s as well.  Is this not the case?
> >>
> > 
> > Yes, it also changes the owner and group.
> > 
> >> At any rate, it wouldn''t hurt to check to see if the ACL
is there already.
> >> Do you have a code example that shows how to do that?
> >>
> > 
> > Nope, but you should be able to just use access(2) to determine if you
> > need to add the ACL entry.
> > 
> 
> But that probably won''t work since you won''t be running
as that user yet
> and access(2) would be checking off of a privileged cred.
It''d be easy to use setreuid() to set the real UID to be
gdm''s.

Nico
--

Mark Shellenbaum <Mark.Shellenbaum at Sun.COM> wrote:
> > Nope, but you should be able to just use access(2) to determine if you
> > need to add the ACL entry.
> > 
>
> But that probably won''t work since you won''t be running
as that user yet
> and access(2) would be checking off of a privileged cred.
For this purpose, POSIX propsed eaccess() and Solaris has the flag E_OK.

access(2) was designed to allow suid processec to check whether they would
be able to access a file in case they have not been called suid.

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily