[PATCH] change strsep() behaviour

Hello, some time ago Ingo Oeser tried to replace strtok() and noone seemed to notice. This time it's me who believes to be on this quest. Why? strtok() is not reentrant, it uses a global variable to store some kind of state. As its manpage states: "Don't use this function". But right now almost

[RFC][PATCH] Simple privacy enhancement for /proc/

Hi all, sorry it took me so long before offering another patch for restricting /proc permissions. Real life kept on intervening. Albert, allowing access based on tty sounds nice, but it _is_ expansive. More importantly, perhaps, it would "virtualize" /proc: every user would see different permiss

Re: [RFC][PATCH] Simple privacy enhancement for /proc/

Bodo Eggert schrieb: > On Sun, 10 Apr 2005, Rene Scharfe wrote: > > >>First, configuring via kernel parameters is sufficient. > > > I don't remember: Would a mount option be equally easy to implement? > (Kernel parameters are OK for me, too.) A mount option

Re: [RFC][PATCH] Simple privacy enhancement for /proc/

On Tue, Apr 12, 2005 at 01:29:35AM -0400, Albert Cahalan wrote: > If you really can't allow access based on tty, then at least allow > access if any UID value matches any UID value. Without this, a user > can not always see a setuid program they are running. Yes, that's a bug. Below is a new vers

[PATCH NFS 0/3] Cleanup/fix nfs_block_size() and nfs_block_bits()

[PATCH NFS 0/3] Cleanup/fix nfs_block_size() and nfs_block_bits() The Plan 9 filesystem for Linux had some code which wrongly calculated the size of blocks. A comment said this code has been taken from NFS. Patch 3 of this series contains a fix for the bug, the first two patches are preparation

[PATCH NFS 1/3] Lose second parameter of nfs_block_size().

[PATCH NFS 1/3] Lose second parameter of nfs_block_size(). Most calls to nfs_block_size() were done with a NULL pointer as second parameter anyway. We can simply calculate the number of bits ourselves instead of using that ugly pointer thingy. Signed-off-by: Rene Scharfe <[EMAIL PROTEC

[PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

this is wrong. :-) The patch uses the built-in roundup_pow_of_two() instead. Signed-off-by: Rene Scharfe <[EMAIL PROTECTED]> --- fs/nfs/inode.c | 22 +++--- 1 files changed, 3 insertions(+), 19 deletions(-) 4130722d1eeb5eb22c38df9f09dfa6be554bc72c diff --git a/fs/nfs/inode.

[PATCH NFS 2/3] Lose second parameter of nfs_block_bits

[PATCH NFS 2/3] Lose second parameter of nfs_block_bits Two of the three calls were passing a NULL pointer and we can simply calculate the number of bits ourselves. Signed-off-by: Rene Scharfe <[EMAIL PROTECTED]> --- fs/nfs/inode.c | 17 - 1 files changed, 8 insertions

Re: [PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

, which explicitly states the intent of nfs_block_bits()? It still needs patch 1 and 2. Thanks, Rene [PATCH 3/4] Simplify and rename nfs_block_bits() to rounddown_pow_of_two() nfs_block_bits() doesn't have a lot to do with bits anymore. It can also be implemented simpler and clearer

Re: [PATCH 2/7] procfs privacy: tasks/processes lookup

Lorenzo Hernández García-Hierro schrieb: > This patch restricts non-root users to view only their own processes. You may also want to have a look at the patches I submitted over the last few weeks that restricted some file permissions in /proc// and the comments I received. Regards, Rene - To uns

Re: [PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

own_pow_of_two() belongs in kernel.h next to roundup_pow_of_two(). And maybe it should get a shorter name. Anyway, I also don't like "nfs_blocksize_align". So let's simply keep the old name. Renaming can be done later if really needed. Rene [PATCH 3/3] Simplify nfs_block_b

[PATCH][RFC] Make /proc/ chmod'able

OK, folks, another try to enhance privacy by hiding process details from other users. Why not simply use chmod to set the permissions of /proc/ directories? This patch implements it. Children processes inherit their parents' proc permissions on fork. You can only set (and remove) read and execu

Re: [PATCH][RFC] Make /proc/ chmod'able

Albert Cahalan wrote: This is a bad idea. Users should not be allowed to make this decision. This is rightly a decision for the admin to make. Why do you think users should not be allowed to chmod their processes' /proc directories? Isn't it similar to being able to chmod their home directories?

Re: [PATCH][RFC] Make /proc/ chmod'able

Albert Cahalan wrote: Note that the admin hopefully does not normally run as root. The admin should be using a normal user account most of the time, to reduce the damage caused by his accidents. Openwall and GrSecurity solved this by having a special group that can see everything, just like root.

Re: [PATCH][RFC] Make /proc/ chmod'able

Albert Cahalan wrote: This really isn't about security. Privacy may be undesirable. I agree, privacy is not security. My patch tries to enhance privacy without giving up security. You think losing the social pressure that comes with mutual surveillance results in loss of security, I don't. Now

Re: [PATCH][RFC] /proc umask and gid [was: Make /proc/ chmod'able]

So, I gather from the feedback I've got that chmod'able /proc/ would be a bit over the top. 8-) While providing the easiest and most intuitive user interface for changing the permissions on those directories, it is overkill. Paul is right when he says that such a feature should be turned on or of

Re: [PATCH][RFC] /proc umask and gid [was: Make /proc/ chmod'able]

On Tue, Mar 15, 2005 at 11:41:28PM -0500, Albert Cahalan wrote: > Better interface: > > /sbin/sysctl -w proc.maps=0440 > /sbin/sysctl -w proc.cmdline=0444 > /sbin/sysctl -w proc.status=0444 Indeed it is, but it's much harder to implement. Patch is against 2.6.11-mm3 but works with -mm4, too. I

[PATCH][0/6] Change proc file permissions with sysctls

The following patches implement another interface that allows an admin to restrict permissions inside /proc/ 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/. It work

[PATCH][2/5] Sysctl for proc

Add an array to store file permission settings in and add an example sysctl (proc.cmdline). It can already be set and read, but it has no effect, yet. diff -pur l1/fs/proc/base.c l2/fs/proc/base.c --- l1/fs/proc/base.c 2005-03-19 01:28:47.0 +0100 +++ l2/fs/proc/base.c 2005-03-19 19:50

[PATCH][5/5] Four more sysctls

Add four more sysctls: proc.maps, proc.stat, proc.statm, proc.status. diff -pur l1/fs/proc/base.c l2/fs/proc/base.c --- l1/fs/proc/base.c 2005-03-19 20:10:22.0 +0100 +++ l2/fs/proc/base.c 2005-03-19 20:11:38.0 +0100 @@ -149,11 +149,11 @@ static struct pid_entry tgid_base_stuff[

[PATCH][4/5] Add inode_operations for proc sysctl

Add getattr and permission inode_operations for base /proc/ entries that make sure the value of inode->i_mode is up-to-date with its respective sysctl setting. This is achieved by calling the new function proc_update_mode. It currently spares the init process. diff -pur l1/fs/proc/base.c l2/fs/p

[PATCH][3/5] New member for proc_inode: ctl_name

Add new field to struct proc_inode and struct pid_entry: ctl_name. It will be used to hold the ctl_name value of the sysctl that is responsible for the respective inode or pid_entry. Also initialize this value for our example sysctl (proc.cmdline). diff -pur l1/fs/proc/base.c l2/fs/proc/base.c -

[PATCH][1/5] Introduce proc_domode

[The patches seem to not have made it to the list the first time, I'm retrying without CC:s.] Add a new sysctl proc handler , proc_domode. It can be used to implement sysctls for setting and/or displaying file mode or file mask values. diff -pur l1/include/linux/sysctl.h l2/include/linux/sysctl.

[PATCH][6/5] Bonus: unrelated minor cleanup of enum pid_directory_inos

Cleanup: remove PROC_TGID_FD_DIR because it's unused. Also put PROC_TID_FD_DIR at the end of the enum to avoid clashing of the FD range (as noted in the comment) with PROC_TID_OOM_SCORE and PROC_TID_OOM_ADJUST. It's not a _problem_, because FD links and these OOM related files are in different di

Re: [PATCH][1/5] Introduce proc_domode

Jan Engelhardt wrote: +#define MAXMODE 0 I think this should be 0777. SUID, SGID and sticky bit do not belong into /proc. It's not /proc specific, the function proc_domode can be used for all kinds of sysctls. It enforces a maximum mode, specified in the ->extra1 member of a sysctl table ent

[PATCH] remove mount option parsing from procfs

OK, my previous patches on the subject were _so_ bad that noone even bothered to flame me. Here's an attempt to fix this. :] This patch removes the mount options of the proc filesystem. They don't have any effect since 2.4.something. Explanation: Only proc_fill_super() calls parse_options, nota

[PATCH] add umask parameter to procfs

Add proc.umask kernel parameter. It can be used to restrict permissions on the numerical directories in the root of a proc filesystem, i.e. the directories containing process specific information. E.g. add proc.umask=077 to your kernel command line and all users except root can only see their own

Re: [PATCH] add umask parameter to procfs

On Fri, Feb 18, 2005 at 04:56:01AM +0100, Herbert Poetzl wrote: > hmm, so what about debugger and similar not able to find the > parent process or something like that? You can walk the parentage chain up until you reach your login shell. So you can look up info about the parent of every one of you

[PATCH] Restrict procfs permissions

Hi all, this patch adds a umask option to the proc filesystem. It can be used to restrict the permission of users to view each others process information. E.g. on a multi-user shell server one could use a setting of umask=077 to allow all users to view info about their own processes, only. It s

Re: [PATCH] Restrict procfs permissions

Al Viro wrote: On Sat, Jan 29, 2005 at 03:45:42AM +0100, Rene Scharfe wrote: The patch is inspired by the /proc restriction parts of the GrSecurity patch. The main difference is the ability to configure the restrictions dynamically. You can change the umask setting by running # mount -o remount

[PATCH] proc filesystem (1/3): fix mount options

Hello, while trying to add a umask option to the proc filesystem I stumbled over a somewhat related problem: the existing mount options uid and gid were non-functional. The patch below is an attempt to fix them and prepares the ground for my evil umask plans. :) The first half of the reason why

[PATCH] proc filesystem (3/3): add proc_show_options()

This patch adds a show_options function to the proc filesystem. diff -pur l2/fs/proc/inode.c l3/fs/proc/inode.c --- l2/fs/proc/inode.c 2005-02-01 04:51:23.0 +0100 +++ l3/fs/proc/inode.c 2005-02-01 04:51:07.0 +0100 @@ -16,6 +16,7 @@ #include #include #include +#include #

[PATCH] proc filesystem (2/3): add umask option

This patch adds the umask option to the proc filesystem. It's essentially unchanged from the previous version, except that the mount option has to be specified as a kernel parameter now. This way we avoid dealing with pre-existing inodes. The umask can be used to restrict the permissions of proc

[PATCH][RFC] Apply umask to /proc/

Hi all, patch below makes procfs apply the umask of the processes to their respective /proc/ 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

[PATCH] strtok -> strsep (The Easy Cases)

Hello, the patch at the bottom does the bulk job of strtok replacement. It's a very boring patch, containing easy cases, only. It became a bit big, too, but I trust you can digest it nevertheless. It's made against kernel version 2.4.4. What is the benefit of getting rid of strtok? It is for cut

Re: [PATCH] strtok -> strsep (The Easy Cases)

Am Freitag, 4. Mai 2001 02:57 schrieb Rusty Russell: > In message <01050120580701.01713@golmepha> you write: > > Hello, Hi! > > > > the patch at the bottom does the bulk job of strtok replacement. It's a > > very boring patch, containing easy cases, only. It became a bit big, too, > > but I tru