[PATCH][RFC] Apply umask to /proc/<pid>

[PATCH][RFC] Apply umask to /proc/<pid>

[Rene Scharfe]

Hi all,

patch below makes procfs apply the umask of the processes to their
respective /proc/<pid> directories and the files below them.  That
allows users to gain a bit of privacy by setting a restrictive umask in
their profiles.

Unlike my previous patches on that subject it requires no new parameter
or mount option and puts control into the hands of the user owning those
files.  And it's even smaller and simpler, too. :]

A umask change only affects processes created after the change with
certainty.  The /proc files of a process changing its own umask may or
may not be affected, depending on whether their inode already exists.
That's OK, I think, and fits within the conventional meaning of umask.

Tools like top and ps continue to work, they simply don't show processes
that the user running them has no permission to get details on.  Even
pstree works as long as the umask of init is kept at its permissive default
value.

Comments welcome!

Rene



--- linux-2.6.11-bk8/fs/proc/base.c~	2005-03-12 19:11:37.000000000 +0100
+++ linux-2.6.11-bk8/fs/proc/base.c	2005-03-12 19:12:53.000000000 +0100
@@ -1418,6 +1418,8 @@ static struct file_operations proc_tgid_
 static struct inode_operations proc_tgid_attr_inode_operations;
 #endif
 
+#define proc_get_umask(task) (task->fs ? task->fs->umask : 0)
+
 /* SMP-safe */
 static struct dentry *proc_pident_lookup(struct inode *dir, 
 					 struct dentry *dentry,
@@ -1450,7 +1452,7 @@ static struct dentry *proc_pident_lookup
 		goto out;
 
 	ei = PROC_I(inode);
-	inode->i_mode = p->mode;
+	inode->i_mode = p->mode & ~proc_get_umask(task);
 	/*
 	 * Yes, it does not scale. And it should not. Don't add
 	 * new entries into /proc/<tgid>/ without very good reasons.
@@ -1796,7 +1798,7 @@ struct dentry *proc_pid_lookup(struct in
 		put_task_struct(task);
 		goto out;
 	}
-	inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO;
+	inode->i_mode = (S_IFDIR|S_IRUGO|S_IXUGO) & ~proc_get_umask(task);
 	inode->i_op = &proc_tgid_base_inode_operations;
 	inode->i_fop = &proc_tgid_base_operations;
 	inode->i_nlink = 3;
@@ -1851,7 +1853,7 @@ static struct dentry *proc_task_lookup(s
 
 	if (!inode)
 		goto out_drop_task;
-	inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO;
+	inode->i_mode = (S_IFDIR|S_IRUGO|S_IXUGO) & ~proc_get_umask(task);
 	inode->i_op = &proc_tid_base_inode_operations;
 	inode->i_fop = &proc_tid_base_operations;
 	inode->i_nlink = 3;

Re: [PATCH][RFC] Apply umask to /proc/<pid>

[Paul Jackson]

> patch below makes procfs apply the umask of the processes to their
> respective /proc/<pid> directories and the files below them.

Ugh ...

Since there are already various umask settings done by various
/etc/*profile* and /etc/*init* scripts that head up various logins and
task families, this means that the default visibility of tasks in ps and
top will change.  I predict confusion and frustration, when people don't
know why portions of ps or top output are suppressed.

And even when they figure it out, you don't give them anyway to get back
to the previous state - of visibility in ps, top and pstree, but file
creation permissions masked off in some way.

Nice small patch ... but I don't like overloading umask with this.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

Re: [PATCH][RFC] Apply umask to /proc/<pid>

[Bodo Eggert]

Rene Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:

> patch below makes procfs apply the umask of the processes to their
> respective /proc/<pid> directories and the files below them.  That
> allows users to gain a bit of privacy by setting a restrictive umask in
> their profiles.

A [ur]limit-like value is fine, but allowing others to read the files you
put into a public directory should not imply giving up your privacy.