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;
Rene Scharfe <[email protected]> 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.
> 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 <[email protected]> 1.650.933.1373, 1.925.600.0401