Alan Cox wrote:
On Thu, Feb 14, 2008 at 07:54:15AM -0600, Les Mikesell wrote:
Because the device changes ownership
Traditional unix behavior is that open file descriptors stay open and
working even if access permissions change.
Actually no. The tty behaviour has been different since the earliest days
for precisely these reasons
But your /dev/tty is different from my /dev/tty and they stay that way
if we are both logged in.
turn instead of rudely breaking a working process). I can see where
this might make sense on the VT keyboard since that device is
necessarily shared during the procedure. But it doesn't make any more
sense to interrupt a running phone or music player session because
someone else is temporarily using a certain keybord than it would to
break a running tape backup for the same circumstance. Or at least this
should be left as an easily chosen local policy.
And local policy should defalt to security first.
That's fine if there is a sane, documented method to manage policy.
the first session being interrupted has root access anyway and could
bypass the access restrictions the switch tries to impose. Wouldn't it
be better to kernel locking or some mechanism that can really ensure
exclusive access for situations like a phone session?
VT switch locking policy is handled by X, and by X clients, the kernel just
implements the rules.
How does this relate to sessions not tied to a local keyboard? That is,
if my session is via freenx, will a console login break access to the
audio devices?
Your objections really make no rational sense anyway, you don't "accidentally"
switch sessions to another user.
The accidental part is the idea that a certain keyboard is somehow
related to other devices. That might be true in some cases, but it is
just circumstantial. If someone is listening to music through speakers
or has a phone call going he may not be near the keyboard, and someone
else logging in to check their mail would have no relationship at all to
the audio devices.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
