From: Sripathi Kodi <sripathik@in.ibm.com>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH 2.6.13.1] Patch for invisible threads
Date: Fri, 16 Sep 2005 10:06:53 -0500 [thread overview]
Message-ID: <432ADF8D.8010503@in.ibm.com> (raw)
In-Reply-To: <20050916074606.GE19626@ftp.linux.org.uk>
Al Viro wrote:
> Ugh... Considering that all of that is _only_ for /proc/<pid>/task and
> that proc_permission() is a couple of function calls, why bother with
> proc_task_check_root() instead of just adding proc_task_permission() with
>
> {
> struct dentry *root;
> struct vfsmount *vfsmnt;
>
> if (generic_permission(inode, mask, NULL) != 0)
> return -EACCES;
>
> /* or just open-code it here, for that matter */
> if (proc_task_root_link(inode, &root, &vfsmnt))
> return -ENOENT;
>
> return proc_check_chroot(root, vfsmnt);
> }
>
> for a body and leaving proc_permission() without any changes at all?
Al,
Done. Please find the patch below. I retained proc_task_root_link, because
it has significant amount of code in it.
> Right. The real question is whether the current behaviour makes any sense.
> I've no objections to your patch + modification above, but I really wonder
> if we should keep current rules in that area.
I don't know what would be the right behavior for this area. If you have any
ideas for changes we could introduce here, I am ready to code and test it out.
Thanks and regards,
Sripathi.
Signed-off-by: Sripathi Kodi <sripathik@in.ibm.com>
--- linux-2.6.13.1-orig/fs/proc/base.c 2005-09-16 17:22:44.000000000 -0500
+++ linux-2.6.13.1/fs/proc/base.c 2005-09-16 17:08:18.000000000 -0500
@@ -291,6 +291,52 @@ static int proc_root_link(struct inode *
return result;
}
+
+/* Same as proc_root_link, but this addionally tries to get fs from other
+ * threads in the group */
+static int proc_task_root_link(struct inode *inode, struct dentry **dentry,
struct vfsmount **mnt)
+{
+ struct fs_struct *fs;
+ int result = -ENOENT;
+ struct task_struct *leader = proc_task(inode);
+
+ task_lock(leader);
+ fs = leader->fs;
+ if (fs) {
+ atomic_inc(&fs->count);
+ task_unlock(leader);
+ } else {
+ /* Try to get fs from other threads */
+ task_unlock(leader);
+ struct task_struct *task = leader;
+ read_lock(&tasklist_lock);
+ if (pid_alive(task)) {
+ while ((task = next_thread(task)) != leader) {
+ task_lock(task);
+ fs = task->fs;
+ if (fs) {
+ atomic_inc(&fs->count);
+ task_unlock(task);
+ break;
+ }
+ task_unlock(task);
+ }
+ }
+ read_unlock(&tasklist_lock);
+ }
+
+ if (fs) {
+ read_lock(&fs->lock);
+ *mnt = mntget(fs->rootmnt);
+ *dentry = dget(fs->root);
+ read_unlock(&fs->lock);
+ result = 0;
+ put_fs_struct(fs);
+ }
+ return result;
+}
+
+
#define MAY_PTRACE(task) \
(task == current || \
(task->parent == current && \
@@ -449,14 +495,14 @@ static int proc_oom_score(struct task_st
/* permission checks */
-static int proc_check_root(struct inode *inode)
+/* If the process being read is separated by chroot from the reading process,
+ * don't let the reader access the threads.
+ */
+static int proc_check_chroot(struct dentry *root, struct vfsmount *vfsmnt)
{
- struct dentry *de, *base, *root;
- struct vfsmount *our_vfsmnt, *vfsmnt, *mnt;
+ struct dentry *de, *base;
+ struct vfsmount *our_vfsmnt, *mnt;
int res = 0;
-
- if (proc_root_link(inode, &root, &vfsmnt)) /* Ewww... */
- return -ENOENT;
read_lock(¤t->fs->lock);
our_vfsmnt = mntget(current->fs->rootmnt);
base = dget(current->fs->root);
@@ -489,6 +535,16 @@ out:
goto exit;
}
+static int proc_check_root(struct inode *inode)
+{
+ struct dentry *root;
+ struct vfsmount *vfsmnt;
+
+ if (proc_root_link(inode, &root, &vfsmnt)) /* Ewww... */
+ return -ENOENT;
+ return proc_check_chroot(root, vfsmnt);
+}
+
static int proc_permission(struct inode *inode, int mask, struct nameidata
*nd)
{
if (generic_permission(inode, mask, NULL) != 0)
@@ -496,6 +552,20 @@ static int proc_permission(struct inode
return proc_check_root(inode);
}
+static int proc_task_permission(struct inode *inode, int mask, struct
nameidata *nd)
+{
+ struct dentry *root;
+ struct vfsmount *vfsmnt;
+
+ if (generic_permission(inode, mask, NULL) != 0)
+ return -EACCES;
+
+ if (proc_task_root_link(inode, &root, &vfsmnt))
+ return -ENOENT;
+
+ return proc_check_chroot(root, vfsmnt);
+}
+
extern struct seq_operations proc_pid_maps_op;
static int maps_open(struct inode *inode, struct file *file)
{
@@ -1355,7 +1425,7 @@ static struct inode_operations proc_fd_i
static struct inode_operations proc_task_inode_operations = {
.lookup = proc_task_lookup,
- .permission = proc_permission,
+ .permission = proc_task_permission,
};
#ifdef CONFIG_SECURITY
next prev parent reply other threads:[~2005-09-16 15:08 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-12 17:46 [PATCH 2.6.13.1] Patch for invisible threads Sripathi Kodi
2005-09-12 20:49 ` Andrew Morton
2005-09-13 13:10 ` Sripathi Kodi
2005-09-13 14:53 ` Linus Torvalds
2005-09-13 16:51 ` Al Viro
2005-09-13 17:01 ` Linus Torvalds
2005-09-13 17:12 ` Al Viro
2005-09-13 21:30 ` Sripathi Kodi
2005-09-13 21:56 ` Roland McGrath
2005-09-13 21:57 ` Al Viro
2005-09-13 23:10 ` Linus Torvalds
2005-09-14 1:47 ` Sripathi Kodi
2005-09-14 1:52 ` Al Viro
2005-09-14 14:37 ` Bill Davidsen
2005-09-15 0:30 ` Sripathi Kodi
2005-09-14 1:50 ` Al Viro
2005-09-15 0:31 ` Sripathi Kodi
2005-09-15 0:55 ` Roland McGrath
2005-09-15 1:38 ` Sripathi Kodi
2005-09-15 2:12 ` Al Viro
2005-09-15 7:29 ` Roland McGrath
2005-09-15 1:18 ` Al Viro
2005-09-16 0:54 ` Sripathi Kodi
2005-09-16 7:46 ` Al Viro
2005-09-16 15:06 ` Sripathi Kodi [this message]
2005-09-16 18:05 ` Daniel Jacobowitz
2005-09-16 18:14 ` Al Viro
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=432ADF8D.8010503@in.ibm.com \
--to=sripathik@in.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=torvalds@osdl.org \
--cc=viro@ZenIV.linux.org.uk \
--cc=viro@ftp.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 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.