[patch 0/2] Tmpfs acls

[patch 0/2] Tmpfs acls

[Andreas Gruenbacher]

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 <agruen@suse.de>
SUSE Labs, SUSE LINUX Products GmbH / Novell Inc.

Re: [patch 0/2] Tmpfs acls

[Matthew Garrett]

Andreas Gruenbacher <agruen@suse.de> 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 | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: [patch 0/2] Tmpfs acls

[Andreas Gruenbacher]

On Monday 09 January 2006 00:34, Matthew Garrett wrote:
> Andreas Gruenbacher <agruen@suse.de> 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

Re: [patch 0/2] Tmpfs acls

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: [patch 0/2] Tmpfs acls

[Kay Sievers]

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

Re: [patch 0/2] Tmpfs acls

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: [patch 0/2] Tmpfs acls

[Alan Cox]

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 ?

Re: [patch 0/2] Tmpfs acls

[Gabor Gombas]

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
     ---------------------------------------------------------

[patch 0/2] Tmpfs acls

[Andreas Gruenbacher]

This is a refresh of the patches we have to support POSIX ACLs on tmpfs,
with the request for inclusion.

The patches solve the following problem: We want to grant access to
devices based on who is logged in from where, etc. This includes
switching back and forth between multiple user sessions, etc.

Using ACLs to define device access for logged-in users gives us all the
flexibility we need in order to fully solve the problem.

Device special files nowadays usually live on tmpfs, hence tmpfs ACLs.

Different distros have come up with solutions that solve the problem to
different degrees: SUSE uses a resource manager which tracks login
sessions and sets ACLs on device inodes as appropriate. RedHat uses
pam_console, which changes the primary file ownership to the logged-in
user. Others use a set of groups that users must be in in order to be
granted the appropriate accesses.

The freedesktop.org project plans to implement a combination of a
console-tracker and a HAL-device-list based solution to grant access to
devices to users, and more distros will likely follow this approach.

-

These patches have first been posted here on 2 February 2005, and again
on 8 January 2006. We have been shipping them in SLES9 and SLES10 with
no problems reported.  The previous submission is archived here:

   http://lkml.org/lkml/2006/1/8/229
   http://lkml.org/lkml/2006/1/8/230
   http://lkml.org/lkml/2006/1/8/231

Could the patches please get included this time?

Andrew, is putting them in -mm for a while fine with you?

Thanks,
Andreas

--
Andreas Gruenbacher <agruen@suse.de>
Novell / SUSE Labs

-- 
VGER BF report: U 0.5