On Mon, 2007-02-12 at 13:22 -0500, Alan Cox wrote: > > Which is not good enough; we need a model where we can make a > > distinction between the actual sessions so we can deny service to > > sessions depending on whether they are active / local or whatnot. Do you > > agree this is an important goal? What guarantees we make, and more > > I don't understand why you require security for this. I can see why it is > useful in an advisory manner (typing reboot in the wrong window failing > because it is remote even though I have a local session on the tagret box > may save a few backsides by avoiding errors) Two sessions in fast user switching on a single seat. One web cam. You really want to make sure that the inactive session cannot use the web cam. Yes, to do this in a really secure manner you want revoke() and probably something even better than this proposal http://lwn.net/Articles/192632/ E.g. we want to say "revoke all access to /dev/video for processes in this or that session". Without revoke we can at least remove ACL's on the device file. > If your model is that there are some set of users who have processes > on the system, and that 1 or more of those users are members of a subset > who have 'special powers' because at that moment they posess a session which > is 'active', 'local', etc then you need to ensure that the privileged > agent which manages the creation of sessions/switching of active session and > the privileged agents which implement the special powers share a common > dynamic list/database indicating which uids are currently entitled to exercise > special powers. That's called ConsoleKit, please see http://fedoraproject.org/wiki/Desktop/FastUserSwitching for details. Entities that manage e.g. device file permissions can hook into this to add / remove ACL's on devices as well as calling revoke() (if that is available) on session switching. David -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
