public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Johansen <john.johansen@canonical.com>
To: John Johansen <john.johansen@canonical.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	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: Sat, 20 Feb 2010 09:25:10 -0800	[thread overview]
Message-ID: <4B801AF6.20003@canonical.com> (raw)
In-Reply-To: <4B7FD2F0.6090602@canonical.com>

John Johansen wrote:
> Al Viro wrote:
>> 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(&current->fs->lock);
>>> +	root = current->fs->root;
>>> +	/* released below */
>>> +	path_get(&root);
>>> +	read_unlock(&current->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.
>>
> Right, though the ns_root.mnt and ns_root.dentry are needed below to detect
> disconnected paths.
> 
Well no, actually I don't need it.  After looking at this again,
If struct path tmp is unmodified we hit our expected root.

  reply	other threads:[~2010-02-20 17:25 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
2010-02-20 12:17     ` John Johansen
2010-02-20 17:25       ` John Johansen [this message]
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=4B801AF6.20003@canonical.com \
    --to=john.johansen@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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