user/sven/linux.git/kernel/user.c, branch v2.6.12.2

[PATCH] base-small: shrink UID hash

2005-03-08T02:03:54Z

CONFIG_BASE_SMALL reduce UID lookup hash Signed-off-by: Matt Mackall Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Lock initializer cleanup (Core)

2005-01-08T06:09:06Z

Kernel core files converted to use the new lock initializers. Signed-off-by: Thomas Gleixner Acked-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] implement in-kernel keys & keyring management

2004-10-19T00:58:51Z

The feature set the patch includes: - Key attributes: - Key type - Description (by which a key of a particular type can be selected) - Payload - UID, GID and permissions mask - Expiry time - Keyrings (just a type of key that holds links to other keys) - User-defined keys - Key revokation - Access controls - Per user key-count and key-memory consumption quota - Three std keyrings per task: per-thread, per-process, session - Two std keyrings per user: per-user and default-user-session - prctl() functions for key and keyring creation and management - Kernel interfaces for filesystem, blockdev, net stack access - JIT key creation by usermode helper There are also two utility programs available: (*) http://people.redhat.com/~dhowells/keys/keyctl.c A comprehensive key management tool, permitting all the interfaces available to userspace to be exercised. (*) http://people.redhat.com/~dhowells/keys/request-key An example shell script (to be installed in /sbin) for instantiating a key. Signed-Off-By: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] rlimit-based mlocks for unprivileged users

2004-08-23T06:06:46Z

Here is the last agreed-on patch that lets normal users mlock pages up to their rlimit. This patch addresses all the issues brought up by Chris and Andrea. From: Chris Wright Couple more nits. The default lockable amount is one page now (first patch is was 0). Why don't we keep it as 0, with the CAP_IPC_LOCK overrides in place? That way nothing is changed from user perspective, and the rest of the policy can be done by userspace as it should. This patch breaks in one scenario. When ulimit == 0, process has CAP_IPC_LOCK, and does SHM_LOCK. The subsequent unlock or destroy will corrupt the locked_shm count. It's also inconsistent in handling user_can_mlock/CAP_IPC_LOCK interaction betwen shm_lock and shm_hugetlb. SHM_HUGETLB can now only be done by the shm_group or CAP_IPC_LOCK. Not any can_do_mlock() user. Double check of can_do_mlock isn't needed in SHM_LOCK path. Interface names user_can_mlock and user_substract_mlock could be better. Incremental update below. Ran some simple sanity tests on this plus my patch below and didn't find any problems. * Make default RLIM_MEMLOCK limit 0. * Move CAP_IPC_LOCK check into user_can_mlock to be consistent and fix but with ulimit == 0 && CAP_IPC_LOCK with SHM_LOCK. * Allow can_do_mlock() user to try SHM_HUGETLB setup. * Remove unecessary extra can_do_mlock() test in shmem_lock(). * Rename user_can_mlock to user_shm_lock and user_subtract_mlock to user_shm_unlock. * Use user instead of current->user to fit in 80 cols on SHM_LOCK. Signed-off-by: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] RLIM: add mq_bytes to user_struct

2004-06-18T00:57:07Z

Add mq_bytes field to user_struct, and make sure it's properly initialized. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] RLIM: add sigpending field to user_struct

2004-06-18T00:56:32Z

Add sigpending field to user_struct, and make sure it's properly initialized. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] slab: consolidate panic code

2004-05-22T15:01:17Z

Many places do: if (kmem_cache_create(...) == NULL) panic(...); We can consolidate all that by passing another flag to kmem_cache_create() which says "panic if it doesn't work".

[PATCH] find_user locking and leak fix

2004-05-10T07:00:52Z

find_user() is being called from set/get_priority(), but it doesn't take the needed lock, and those callers were forgetting to drop the refcount which find_user() took.

[PATCH] uidhash init-time locking

2003-08-01T03:10:03Z

From: Add the necessary locking around uid_hash_insert() in uid_cache_init(). (It's an initcall, and the chances of another CPU racing with us here are basically zero. But it's good for documentary purposes and the code gets dropped later anyway...)

[PATCH] fix current->user->__count leak

2003-07-05T02:38:06Z

From: Arvind Kandhare When switch_uid is called, the reference count of the new user is incremented twice. I think the increment in the switch_uid is done because of the reparent_to_init() function which does not increase the __count for root user. But if switch_uid is called from any other function, the reference count is already incremented by the caller by calling alloc_uid for the new user. Hence the count is incremented twice. The user struct will not be deleted even when there are no processes holding a reference count for it. This does not cause any problem currently because nothing is dependent on timely deletion of the user struct.