From: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
To: linux-kernel@vger.kernel.org
Cc: albert@users.sf.net, akpm@osdl.org,
viro@parcelfarce.linux.theplanet.co.uk, pj@engr.sgi.com,
7eggert@gmx.de
Subject: [PATCH][0/6] Change proc file permissions with sysctls
Date: Sun, 20 Mar 2005 01:22:42 +0100 [thread overview]
Message-ID: <1111278162.22BA.5209@neapel230.server4you.de> (raw)
In-Reply-To:
The following patches implement another interface that allows an admin
to restrict permissions inside /proc/<pid> to enhance the privacy of
users. Following a suggestion by Albert Calahan this set of patches
introduces five sysctls, each one changes the permissions of a certain
file in /proc/<pid>.
It works by implementing getattr and permission methods that update the
files' permissions (btw. Al Viro suggested doing it this way right from
the start..).
To "cloak" as much as currently possible:
# sysctl -q proc.cmdline=0400
# sysctl -q proc.maps=0400
# sysctl -q proc.stat=0400
# sysctl -q proc.statm=0400
# sysctl -q proc.status=0400
This will set the permissions of /proc/*/cmdline etc. to the given
value.
The permissions of files in /proc/1 (usually belonging to init) are
kept as they are. The idea is to let system processes be freely
visible by anyone, just as before. Especially interesting in this
regard would be instances of login. I don't know how to easily
discriminate between system processes and "normal" processes inside
the kernel (apart from pid == 1 and uid == 0 (which is too broad)).
Any ideas?
It's easy to make more files' permissions configurable, if the need
arises.
This implementation is a lot bigger than the quick hacks I sent earlier.
Is this feature growing too fat? Also I'm unsure about the #ifdef'ery
in fs/proc/base.c, I just wanted to be consistent with the surrounding
code. :-P
Rene
next reply other threads:[~2005-03-20 0:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-20 0:22 Rene Scharfe [this message]
2005-03-20 4:22 ` Bodo Eggert
2005-03-20 6:08 ` Albert Cahalan
2005-03-20 9:48 ` Jan Engelhardt
2005-03-20 10:14 ` [PATCH][4/5] Add inode_operations for proc sysctl Rene Scharfe
2005-03-20 10:14 ` [PATCH][5/5] Four more sysctls Rene Scharfe
2005-03-20 10:14 ` [PATCH][2/5] Sysctl for proc Rene Scharfe
2005-03-20 10:14 ` [PATCH][3/5] New member for proc_inode: ctl_name Rene Scharfe
2005-03-20 10:14 ` [PATCH][1/5] Introduce proc_domode Rene Scharfe
2005-03-20 10:32 ` Jan Engelhardt
2005-03-20 10:40 ` Rene Scharfe
2005-03-20 10:14 ` [PATCH][6/5] Bonus: unrelated minor cleanup of enum pid_directory_inos Rene Scharfe
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=1111278162.22BA.5209@neapel230.server4you.de \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=7eggert@gmx.de \
--cc=akpm@osdl.org \
--cc=albert@users.sf.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@engr.sgi.com \
--cc=viro@parcelfarce.linux.theplanet.co.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
all inboxes | Powered by JetHome®