public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE][PATCH] New fs to control access to system resources
Date: Fri, 18 Jan 2002 11:38:46 -0800	[thread overview]
Message-ID: <20020118193846.GE13310@kroah.com> (raw)
In-Reply-To: <87k7uj61tk.fsf@tigram.bogus.local> <20020116195105.C18039@devcon.net> <20020116230620.GE3410@kroah.com> <20020117102650.A1742@devcon.net>
In-Reply-To: <20020117102650.A1742@devcon.net>

On Thu, Jan 17, 2002 at 10:26:51AM +0100, Andreas Ferber wrote:
> 
> My concern was conceptual: accessfs is just another mechanism for
> access control to various ressources. As I understand it, LSM is
> intended to move /all/ access control logic into separate modules with
> a uniform interface to the kernel, so that you can choose whatever
> access control mechanism you want (or even rip out all access control,
> as for example some embedded applications don't need it). Clearly it's
> a long way until LSM actually gets to this point, but nevertheless
> it's the overall goal of the whole effort IMHO.

The LSM patch's goal is to only _allow_ you do add access control
mechanisms to the kernel easily.

This accessfs patch doesn't collide with that goal at all.  If it gets
accepted into the kernel, people who write LSM based access control
modules need to remember to medaite access to the accessfs if they want
to.  Since the LSM hooks are much lower in the vfs than accessfs, it is
a simple thing to add this kind of access mediation.

Hope this helps clear it up a bit.

thanks,

greg k-h

  reply	other threads:[~2002-01-18 19:43 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-15 16:01 [ANNOUNCE][PATCH] New fs to control access to system resources Olaf Dietsche
2002-01-15 16:53 ` Richard Gooch
2002-01-15 17:38   ` Wichert Akkerman
2002-01-15 17:54     ` Richard Gooch
2002-01-15 17:48   ` Olaf Dietsche
2002-01-16 19:05   ` Andreas Ferber
2002-01-15 22:13 ` Ben Clifford
2002-01-15 22:24   ` Measuring execution time Mark Cuss
2002-01-16 17:23     ` Chris Friesen
2002-01-16 17:53       ` Richard B. Johnson
2002-01-16 21:47       ` Jakob Østergaard
2002-01-16 17:18   ` [ANNOUNCE][PATCH] New fs to control access to system resources Olaf Dietsche
2002-01-16 18:26     ` Ben Clifford
2002-01-17  0:34       ` Olaf Dietsche
2002-01-15 22:51 ` CaT
2002-01-15 23:00   ` David Weinehall
2002-01-15 23:13     ` CaT
2002-01-16  4:19 ` dean gaudet
2002-01-16 17:18   ` Olaf Dietsche
2002-01-16 18:12     ` dean gaudet
2002-01-17  0:34       ` Olaf Dietsche
2002-01-16 18:51 ` Andreas Ferber
2002-01-16 13:38   ` gmack
2002-01-16 23:06   ` Greg KH
2002-01-17  9:26     ` Andreas Ferber
2002-01-18 19:38       ` Greg KH [this message]
2002-01-18 15:36 ` Anthony DeRobertis
2002-01-18 18:22   ` Olaf Dietsche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020118193846.GE13310@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox