On 11/22/05 05:52, Darren J Moffat wrote:
On Tue, 2005-11-22 at 11:59, Robert Lunnon wrote:
Having thought about my recent dialogue about CDROM door locking it occurs to
me that we really have two different classes of users with different
requirements. It then occurred to me that perhaps the behaviour of the CDROM
should be determined by the "Role" the workstation is playing. For example if
the role is "workstation" then the user should be allowed to eject the cd at
any time and the eject facility on the CDROM drive should not be disabled.
Whereas if the role is multiuser focused (eg server or say terminal server)
then the CD door should be locked when it is busy.
There are probably dozens of other instances like this where behaviour should
be tailored to role. Perhaps we need to consider infrastructure to do this.
We have most of that already between logindevperm and RBAC.
cdrw(1) uses RBAC authorisations to determine if the user can
write to CDs since the device nodes are still owned by root and
cdrw(1) is setuid.
You could instead use logindevperm to assign ownership of the
device nodes to the user who logged in on /dev/console - as we do
for audio and usb mass storage devices. However this is slightly
tricker for CD/DVD writers as the device node alone doesn't tell
you what it is.
I agree that many of the pieces are already there, but there is nothing
tying them together. For example, when you create a user account, there
is no simple way to say this user is the "admin" for this laptop. Or as
Bob suggested, when installing the machine say this is a laptop and the
install software knows there are some packages to add (or not add) and
certain feature that should be enabled.
This lack of tying the technologies together into solutions is where we
are suffering.
my thoughts ....
--jc
_______________________________________________
opensolaris-discuss mailing list
[email protected]
