From: Al Viro <viro@ZenIV.linux.org.uk>
To: john.johansen@canonical.com
Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org
Subject: Re: [PATCH 01/12] Miscellaneous functions and defines needed by AppArmor, including the base path resolution routines.
Date: Fri, 19 Feb 2010 11:03:21 +0000 [thread overview]
Message-ID: <20100219110320.GL30031@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1266572188-26529-2-git-send-email-john.johansen@canonical.com>
On Fri, Feb 19, 2010 at 01:36:17AM -0800, john.johansen@canonical.com wrote:
> +static int d_namespace_path(struct path *path, char *buf, int buflen,
> + char **name, int flags)
> +{
> + struct path root, tmp, ns_root = { };
> + char *res;
> + int deleted, connected;
> + int error = 0;
> +
> + read_lock(¤t->fs->lock);
> + root = current->fs->root;
> + /* released below */
> + path_get(&root);
> + read_unlock(¤t->fs->lock);
> +
> + spin_lock(&vfsmount_lock);
> + if (root.mnt && root.mnt->mnt_ns)
> + /* released below */
> + ns_root.mnt = mntget(root.mnt->mnt_ns->root);
> + if (ns_root.mnt)
> + /* released below */
> + ns_root.dentry = dget(ns_root.mnt->mnt_root);
> + spin_unlock(&vfsmount_lock);
Junk. You might as well leave ns_root {NULL, NULL} instead of that crap.
> + spin_lock(&dcache_lock);
> + /* There is a race window between path lookup here and the
> + * need to strip the " (deleted) string that __d_path applies
> + * Detect the race and relookup the path
> + *
> + * The stripping of (deleted) is a hack that could be removed
> + * with an updated __d_path
Yes, it could. Where's the patch doing just that? Or discussion of
desired interface, at lease...
> + if (flags & PATH_CHROOT_REL)
> + connected = tmp.dentry == root.dentry && tmp.mnt == root.mnt;
> + else
> + connected = tmp.dentry == ns_root.dentry &&
> + tmp.mnt == ns_root.mnt;
> +
> + if (!connected &&
> + !(flags & PATH_CONNECT_PATH) &&
> + !((flags & PATH_CHROOT_REL) && (flags & PATH_CHROOT_NSCONNECT) &&
> + (tmp.dentry == ns_root.dentry && tmp.mnt == ns_root.mnt))) {
> + /* disconnected path, don't return pathname starting with '/' */
> + error = -ESTALE;
> + if (*res == '/')
> + *name = res + 1;
Explanations, please.
next prev parent reply other threads:[~2010-02-19 11:03 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-19 9:36 [AppArmor #4 0/12] AppArmor security module john.johansen
2010-02-19 9:36 ` [PATCH 01/12] Miscellaneous functions and defines needed by AppArmor, including the base path resolution routines john.johansen
2010-02-19 11:03 ` Al Viro [this message]
2010-02-20 12:17 ` John Johansen
2010-02-20 17:25 ` John Johansen
2010-02-20 19:10 ` John Johansen
2010-02-20 12:24 ` John Johansen
2010-02-19 9:36 ` [PATCH 02/12] Update kenel audit range comments to show AppArmor's registered range of 1500-1599. This range used to be reserved for LSPP but LSPP uses the SELinux range and the range was given to AppArmor. Patch is not in mainline -- pending AppArmor code submission to lkml john.johansen
2010-02-19 9:36 ` [PATCH 03/12] AppArmor contexts attach profiles and state to tasks, files, etc. when a direct profile reference is not sufficient john.johansen
2010-02-19 9:36 ` [PATCH 04/12] The basic routines and defines for AppArmor policy. AppArmor policy is defined by a few basic components. profiles - the basic unit of confinement contain all the information to enforce policy on a task john.johansen
2010-02-19 9:36 ` [PATCH 05/12] A basic dfa matching engine based off the dfa engine in the Dragon Book. It uses simple row comb compression with a check field john.johansen
2010-02-19 9:36 ` [PATCH 06/12] AppArmor policy is loaded in a platform independent flattened binary stream. Verify and unpack the data converting it to the internal format needed for enforcement john.johansen
2010-02-19 9:36 ` [PATCH 07/12] AppArmor /proc/<pid>/attr/* and apparmorfs interfaces to userspace john.johansen
2010-02-19 9:36 ` [PATCH 08/12] AppArmor: file enforcement routines john.johansen
2010-02-19 9:36 ` [PATCH 09/12] AppArmor ipc, rlimit, network and capability routines john.johansen
2010-02-19 9:36 ` [PATCH 10/12] AppArmor routines for controlling domain transitions john.johansen
2010-02-19 9:36 ` [PATCH 11/12] AppArmor hooks to interface with the LSM, module parameters and initialization john.johansen
2010-02-22 22:14 ` Serge E. Hallyn
2010-02-23 7:58 ` John Johansen
2010-02-19 9:36 ` [PATCH 12/12] Kconfig and Makefiles to enable configuration and building of AppArmor john.johansen
2010-02-22 22:16 ` Serge E. Hallyn
2010-02-23 7:45 ` John Johansen
2010-03-03 7:50 ` Kees Cook
2010-02-23 1:59 ` [AppArmor #4 0/12] AppArmor security module Tetsuo Handa
2010-02-23 8:38 ` John Johansen
2010-02-23 8:31 ` Tetsuo Handa
2010-02-23 9:17 ` John Johansen
2010-02-26 3:22 ` Tetsuo Handa
2010-02-26 6:31 ` 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=20100219110320.GL30031@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=john.johansen@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@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