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

2005-07-26 Thread Rene Scharfe
() 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_bits() Signed-off-by: Rene Scharfe [EMAIL

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

2005-07-25 Thread Rene Scharfe
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 with fls(). Signed-off-by: Rene Scharfe [EMAIL PROTECTED] --- fs/nfs

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

2005-07-24 Thread Rene Scharfe
[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().

2005-07-24 Thread Rene Scharfe
[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 PROTECTED

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

2005-07-24 Thread Rene Scharfe
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.c b/fs

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

2005-07-24 Thread Rene Scharfe
[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(+), 9

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

2005-04-20 Thread Rene Scharfe
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/pid/ and the comments I received. Regards, Rene - To

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

2005-04-12 Thread Rene Scharfe
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

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

2005-04-11 Thread Rene Scharfe
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 for procfs would be changable at remount

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

2005-04-10 Thread Rene Scharfe
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

[PATCH][2/5] Sysctl for proc

2005-03-20 Thread Rene Scharfe
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

[PATCH][5/5] Four more sysctls

2005-03-20 Thread Rene Scharfe
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

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

2005-03-20 Thread Rene Scharfe
Add getattr and permission inode_operations for base /proc/pid 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

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

2005-03-20 Thread Rene Scharfe
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

2005-03-20 Thread Rene Scharfe
[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

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

2005-03-20 Thread Rene Scharfe
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

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

2005-03-20 Thread Rene Scharfe
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

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

2005-03-19 Thread Rene Scharfe
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.

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

2005-03-18 Thread Rene Scharfe
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 only

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

2005-03-15 Thread Rene Scharfe
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/pid chmod'able

2005-03-15 Thread Rene Scharfe
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.

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

2005-03-15 Thread Rene Scharfe
So, I gather from the feedback I've got that chmod'able /proc/pid 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

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

2005-03-14 Thread Rene Scharfe
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

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

2005-03-13 Thread Rene Scharfe
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/pid directories? This patch implements it. Children processes inherit their parents' proc permissions on fork. You can only set (and remove) read and

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

2005-03-12 Thread 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

Re: [PATCH] add umask parameter to procfs

2005-02-18 Thread Rene Scharfe
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 your

[PATCH] remove mount option parsing from procfs

2005-02-17 Thread Rene Scharfe
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,

[PATCH] add umask parameter to procfs

2005-02-17 Thread Rene Scharfe
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

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

2005-02-01 Thread rene . scharfe
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()

2005-02-01 Thread rene . scharfe
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 linux/module.h #include

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

2005-02-01 Thread rene . scharfe
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

Re: [PATCH] Restrict procfs permissions

2005-01-29 Thread Rene Scharfe
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] Restrict procfs permissions

2005-01-28 Thread Rene Scharfe
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

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

2001-05-04 Thread Rene Scharfe
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 trust you can

[PATCH] strtok - strsep (The Easy Cases)

2001-05-01 Thread Rene Scharfe
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

[PATCH] change strsep() behaviour

2001-04-20 Thread Rene Scharfe
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