Darren J Moffat wrote:

>>>DJM-2 2.7.2 ACLs for usb etc devices
>>>Are you saying that if user "bob" logins in on vt1 and
>>>user "alice" logins on vt2 then there will be an ACL of
>>>both of them on the audio and usb devices ?
>>Right. Actually at the begining, we wanted to group
>>all these devices (add a console group in the system,
>>and dynamically add/remove the logged in user into
>>the console group upon logging in/out. But ACL seems
>>better than group, so we chose ACL. [it was recommeded
>>by Casper Dik.]
> I agree that an ACL is much better than using a group.
> However see below for what appears to be a TX and
> device allocation interaction.
>>>I don't think this is a good idea.  I'm also concerned
>>>about how this interacts with device allocation and
>>>Trusted Extensions.
>>We don't see any impact on the device allocation
>>and Trusted Extensions.
> What label are the vt devices running at when TX is
> enabled ?
> What happens in this (on TX) case:
> User bob logs in graphically with gdm/dtlogin and allocates
> the audio device.  This means that the audio device
> should only able available to bob.
> Now User alice does a login to /dev/vt2, from what you
> said above there would be an ACL added for Alice even
> though the device is owned by bob because allocate(1M)
> changed the ownership.
> That seems wrong and completely counter to the whole
> purpose of device allocation.
> So I believe you do have interaction with device allocation.  At least
> based on the documentation you have provided, or some
> how it isn't clear to me how this works with
> device allocation.

Currently (without virtual console), both logindevperm(4) and
allocate(1) are not aware of each other (even non-TX):
  Rlogin to a system on which nobody has logged in; allocate
  audio device to Bob, then Bob will own the audio device (
  BSM is enabled); Then Alice logs in on the system console,
  and Alice owns the audio device; When Alice exits, the audio
  device is owned by root.

And when the system is labed in TX, all the devices in /etc/
logindevperm will not be allocatable any more. So in TX, /etc/
logindevperm can be empty, and all these console devices can
be managed by allocate(1) by the system administrator.

In fact, as long as there's more than one program managing these
devices, there's conflict.

So it seems that our ACL proposal for other console devices in
/etc/logindevperm is fine, and it does not introduce any regression.

Reply via email to