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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox