From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Kentaro Takeda <takedakn@nttdata.co.jp>
Cc: linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, haradats@nttdata.co.jp,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Subject: Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions.
Date: Thu, 25 Sep 2008 11:59:54 -0500 [thread overview]
Message-ID: <20080925165954.GA25587@us.ibm.com> (raw)
In-Reply-To: <20080924090338.407746083@nttdata.co.jp>
Quoting Kentaro Takeda (takedakn@nttdata.co.jp):
> Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
So IMO there is some major badness here in the form of copying all of
those functions out of fs/namei.c. I think we need to discuss
case-by-case whether using the functions is appropriate (and hence
they should be made non-static in fs/namei.c), or whether the intended
goal should be met some other way. For instance:
> ---
> security/tomoyo/tomoyo.c | 341 +++++++++++++++++++++++++++++++++++++++++++++++
> security/tomoyo/tomoyo.h | 97 +++++++++++++
> 2 files changed, 438 insertions(+)
>
...
> +static int tmy_path_mknod(struct path *parent, struct dentry *dentry, int mode,
> + unsigned int dev)
> +{
> + struct vfsmount *mnt = parent->mnt;
> + struct inode *dir = parent->dentry->d_inode;
> + int error = 0;
> +
> + switch (mode & S_IFMT) {
> + case S_IFREG:
> + case 0:
> + error = may_create(dir, dentry);
Isn't may_create already done at the top of vfs_mknod() and vfs_create()?
> + if (error)
> + return error;
> + if (!dir->i_op || !dir->i_op->create)
> + return -EACCES; /* shouldn't it be ENOSYS? */
> + break;
> + case S_IFCHR:
> + case S_IFBLK:
> + case S_IFIFO:
> + case S_IFSOCK:
> + error = may_create(dir, dentry);
likewise...
> + if (error)
> + return error;
> + if ((S_ISCHR(mode) || S_ISBLK(mode)) && !capable(CAP_MKNOD))
> + return -EPERM;
likewise...
> + if (!dir->i_op || !dir->i_op->mknod)
> + return -EPERM;
> + error = devcgroup_inode_mknod(mode, dev);
likewise... (except in the case of fifo/sock, devcgroup should not be
consulted as I'm not sure it'll handle that properly - have you tested
tis with the device cgroup enabled?)
> + if (error)
> + return error;
> + break;
> + default:
> + return 0;
> + }
> + switch (mode & S_IFMT) {
> + case S_IFREG:
> + case 0:
> + error = tmy_check_1path_perm(TMY_TYPE_CREATE_ACL, dentry, mnt);
> + break;
> + case S_IFCHR:
> + error = tmy_check_1path_perm(TMY_TYPE_MKCHAR_ACL, dentry, mnt);
> + break;
> + case S_IFBLK:
> + error = tmy_check_1path_perm(TMY_TYPE_MKBLOCK_ACL, dentry, mnt);
> + break;
> + case S_IFIFO:
> + error = tmy_check_1path_perm(TMY_TYPE_MKFIFO_ACL, dentry, mnt);
> + break;
> + case S_IFSOCK:
> + error = tmy_check_1path_perm(TMY_TYPE_MKSOCK_ACL, dentry, mnt);
> + break;
> + }
> + return error;
> +}
-serge
next prev parent reply other threads:[~2008-09-25 17:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 9:03 [TOMOYO #9 (2.6.27-rc7-mm1) 0/6] TOMOYO Linux Kentaro Takeda
2008-09-24 9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions Kentaro Takeda
2008-09-25 16:59 ` Serge E. Hallyn [this message]
2008-09-26 5:38 ` Kentaro Takeda
2008-09-26 13:04 ` Serge E. Hallyn
2008-09-29 4:04 ` Kentaro Takeda
2008-09-30 15:45 ` Serge E. Hallyn
2008-09-30 16:14 ` Stephen Smalley
2008-09-30 16:23 ` Serge E. Hallyn
2008-10-01 8:19 ` Kentaro Takeda
2008-10-01 2:33 ` Casey Schaufler
2008-10-01 5:05 ` Valdis.Kletnieks
2008-10-01 8:23 ` Kentaro Takeda
2008-10-01 21:15 ` Serge E. Hallyn
2008-10-02 5:04 ` Kentaro Takeda
2008-10-02 13:39 ` Serge E. Hallyn
2008-10-03 6:37 ` Kentaro Takeda
2008-10-03 13:09 ` Serge E. Hallyn
2008-10-06 2:19 ` Kentaro Takeda
2008-10-06 16:54 ` Serge E. Hallyn
2008-10-07 6:28 ` Kentaro Takeda
2008-09-24 9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 2/6] Memory and pathname management functions Kentaro Takeda
2008-09-24 9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 3/6] Common functions for TOMOYO Linux Kentaro Takeda
2008-09-24 9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 4/6] Domain transition handler Kentaro Takeda
2008-09-24 9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 5/6] File operation restriction part Kentaro Takeda
2008-09-24 9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 6/6] Kconfig and Makefile Kentaro Takeda
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=20080925165954.GA25587@us.ibm.com \
--to=serue@us.ibm.com \
--cc=haradats@nttdata.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--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.