All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	serue@us.ibm.com, jmorris@namei.org,
	linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, takedakn@nttdata.co.jp,
	haradats@nttdata.co.jp
Subject: Re: [PATCH (mmotm-2008-12-02-17-08)] Introduce security_path_set/clear() hooks.
Date: Sat, 6 Dec 2008 06:16:42 +0000	[thread overview]
Message-ID: <20081206061642.GM28946@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1228513998.21715.75.camel@localhost.localdomain>

On Fri, Dec 05, 2008 at 04:53:18PM -0500, Stephen Smalley wrote:
> > Right. Locations of inserting security_path_set()/security_path_clear() pairs
> > are subset of mnt_want_write()/mnt_drop_write() pairs. Thus, we can insert
> > security_path_set()/security_path_clear() pairs into
> > mnt_want_write()/mnt_drop_write() pairs, if we can tolerate performance
> > regression. According to our rough measurement, there is about 8 - 22% of
> > performance regression. But this approach needs minimum modification to the
> > existing kernel (only two hooks to be inserted).
> 
> I assume you also need separate hooks to cover the read-only open case?
> As for your performance, your implementation of mp_* is clearly
> non-optimal, so I'd expect there is plenty of room for improvement
> there.

And just what will happen if you end up with foo_mkdir() calling something
that does e.g. pathname resolution in fs-controlled private namespace and
creates/removes some files there?

  parent reply	other threads:[~2008-12-06  6:16 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-20 11:25 [TOMOYO #13 (mmotm 2008-11-19-02-19) 00/11] TOMOYO Linux Tetsuo Handa
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 01/11] Introduce security_path_clear() hook Tetsuo Handa
2008-12-01 20:00   ` Stephen Smalley
2008-12-02 10:39     ` Tetsuo Handa
2008-12-02 13:48       ` Stephen Smalley
2008-12-03  8:49         ` Kentaro Takeda
2008-12-03  8:56           ` [PATCH (mmotm-2008-12-02-17-08)] Introduce security_path_set/clear() hooks Kentaro Takeda
2008-12-03 14:13             ` Stephen Smalley
2008-12-04 12:00               ` Tetsuo Handa
2008-12-04 18:20                 ` Serge E. Hallyn
2008-12-04 21:41                   ` [PATCH (mmotm-2008-12-02-17-08)] Introducesecurity_path_set/clear() hooks Tetsuo Handa
2008-12-05 21:53                 ` [PATCH (mmotm-2008-12-02-17-08)] Introduce security_path_set/clear() hooks Stephen Smalley
2008-12-05 23:27                   ` Tetsuo Handa
2008-12-06  5:25                     ` [RFC] Add "reason" parameter to mnt_want_write() Tetsuo Handa
2008-12-06  5:53                       ` Al Viro
2008-12-06  6:16                   ` Al Viro [this message]
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 02/11] Add in_execve flag into task_struct Tetsuo Handa
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 03/11] Singly linked list implementation Tetsuo Handa
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 04/11] Introduce d_realpath() Tetsuo Handa
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 05/11] Memory and pathname management functions Tetsuo Handa
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 06/11] Common functions for TOMOYO Linux Tetsuo Handa
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 07/11] File operation restriction part Tetsuo Handa
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 08/11] Domain transition handler Tetsuo Handa
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 09/11] LSM adapter functions Tetsuo Handa
2008-12-01 20:10   ` Stephen Smalley
2008-12-02 10:40     ` Tetsuo Handa
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 10/11] Kconfig and Makefile Tetsuo Handa
2008-11-20 11:25 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 11/11] MAINTAINERS info Tetsuo Handa
2008-11-29 11:59 ` [TOMOYO #13 (mmotm 2008-11-19-02-19) 00/11] TOMOYO Linux Tetsuo Handa

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=20081206061642.GM28946@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=haradats@nttdata.co.jp \
    --cc=jmorris@namei.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=sds@tycho.nsa.gov \
    --cc=serue@us.ibm.com \
    --cc=takedakn@nttdata.co.jp \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.