This is an update of the tmpfs acl patches against 2.6.15-git4. (The
first version of these patches was posted on 2 February 2005.) We'll
have our /dev tree on tmpfs in the future, and we need acls there to
manage device inode permissions of logged-in users. Other distributions
will be in exactly the same situation, and need this patchset as well.
Andrew, if this stuff looks good enough to you, could you please let it
live in -mm for some time?
Thanks,
Andreas
--
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX Products GmbH / Novell Inc.
Andreas Gruenbacher <[email protected]> wrote:
> This is an update of the tmpfs acl patches against 2.6.15-git4. (The
> first version of these patches was posted on 2 February 2005.) We'll
> have our /dev tree on tmpfs in the future, and we need acls there to
> manage device inode permissions of logged-in users. Other distributions
> will be in exactly the same situation, and need this patchset as well.
Hmm. Do you have any infrastructure for revoking open file descriptors
when a user logs out?
--
Matthew Garrett | [email protected]
On Monday 09 January 2006 00:34, Matthew Garrett wrote:
> Andreas Gruenbacher <[email protected]> wrote:
> > This is an update of the tmpfs acl patches against 2.6.15-git4. (The
> > first version of these patches was posted on 2 February 2005.) We'll
> > have our /dev tree on tmpfs in the future, and we need acls there to
> > manage device inode permissions of logged-in users. Other distributions
> > will be in exactly the same situation, and need this patchset as well.
>
> Hmm. Do you have any infrastructure for revoking open file descriptors
> when a user logs out?
Open file descriptors have nothing to do with it. The device permissions are
set by different pam modules on different distributions (pam_console,
pam_resmgr).
Without acls, permissions are assigned by changing file ownership. With acls,
the respective user or users can be given access as appropriate, which is
more flexible. There are a few cases in which it is desirable to grant access
to a device to more than one locally logged in user. This also obsoletes the
resmgr hack of passing around open file descriptors and several hacks in
applications that use this mechanism, because permissions can be set as
appropriate.
Andreas
On Tue, Jan 10, 2006 at 12:59:46AM +0100, Andreas Gruenbacher wrote:
> On Monday 09 January 2006 00:34, Matthew Garrett wrote:
> > Hmm. Do you have any infrastructure for revoking open file descriptors
> > when a user logs out?
>
> Open file descriptors have nothing to do with it. The device permissions are
> set by different pam modules on different distributions (pam_console,
> pam_resmgr).
Right. But what stops a user writing an application that opens a device,
hangs around after the user logs out and then provides access to the
user when logged in remotely?
Handwavy problem scenario - user A logs in, is given access to the
soundcard. Starts running a program that when given appropriate signals
will record from the system microphone. Logs out. Waits for user B, who
he suspects is having an affair with his wife, and then monitors any
conversations that user B has. ACLs on their own don't seem to solve
this any more than just statically assigning group membership to users.
--
Matthew Garrett | [email protected]
On Tue, Jan 10, 2006 at 12:07:58AM +0000, Matthew Garrett wrote:
> On Tue, Jan 10, 2006 at 12:59:46AM +0100, Andreas Gruenbacher wrote:
> > On Monday 09 January 2006 00:34, Matthew Garrett wrote:
> > > Hmm. Do you have any infrastructure for revoking open file descriptors
> > > when a user logs out?
> >
> > Open file descriptors have nothing to do with it. The device permissions are
> > set by different pam modules on different distributions (pam_console,
> > pam_resmgr).
>
> Right. But what stops a user writing an application that opens a device,
> hangs around after the user logs out and then provides access to the
> user when logged in remotely?
>
> Handwavy problem scenario - user A logs in, is given access to the
> soundcard. Starts running a program that when given appropriate signals
> will record from the system microphone. Logs out. Waits for user B, who
> he suspects is having an affair with his wife, and then monitors any
> conversations that user B has.
That can be solved in the user session handling and not in the kernel.
> ACLs on their own don't seem to solve
> this any more than just statically assigning group membership to users.
Sure, they do. Unlike silly group memberships, the system can provide
ressources to "local" users only.
Kay
On Tue, Jan 10, 2006 at 01:17:01AM +0100, Kay Sievers wrote:
> On Tue, Jan 10, 2006 at 12:07:58AM +0000, Matthew Garrett wrote:
> > Handwavy problem scenario - user A logs in, is given access to the
> > soundcard. Starts running a program that when given appropriate signals
> > will record from the system microphone. Logs out. Waits for user B, who
> > he suspects is having an affair with his wife, and then monitors any
> > conversations that user B has.
>
> That can be solved in the user session handling and not in the kernel.
Without killing every application that they've been left running? How?
The only way I can think of is by checking open files against a
blacklist, which seems, uhm, fragile.
--
Matthew Garrett | [email protected]
On Maw, 2006-01-10 at 01:17 +0100, Kay Sievers wrote:
> > he suspects is having an affair with his wife, and then monitors any
> > conversations that user B has.
>
> That can be solved in the user session handling and not in the kernel.
Exactly how do you plan to do that ?
On Tue, Jan 10, 2006 at 12:07:58AM +0000, Matthew Garrett wrote:
> Handwavy problem scenario - user A logs in, is given access to the
> soundcard. Starts running a program that when given appropriate signals
> will record from the system microphone. Logs out. Waits for user B, who
> he suspects is having an affair with his wife, and then monitors any
> conversations that user B has. ACLs on their own don't seem to solve
> this any more than just statically assigning group membership to users.
This scenario is not a permission but a locking problem. User B should
just claim the microphone exclusively and that should fail if user A
keeps an fd open.
For the generic case maybe a new lock type would be useful, that would
fail iff a process with a different effective UID keeps the device open.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------