17 Jun, 2009

1 commit

  • Move supplementary groups implementation to kernel/groups.c .
    kernel/sys.c already accumulated quite a few random stuff.

    Do strictly copy/paste + add required headers to compile. Compile-tested
    on many configs and archs.

    Signed-off-by: Alexey Dobriyan
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

29 Apr, 2009

1 commit


14 Apr, 2009

1 commit


06 Apr, 2009

1 commit

  • Merge reason: we have gathered quite a few conflicts, need to merge upstream

    Conflicts:
    arch/powerpc/kernel/Makefile
    arch/x86/ia32/ia32entry.S
    arch/x86/include/asm/hardirq.h
    arch/x86/include/asm/unistd_32.h
    arch/x86/include/asm/unistd_64.h
    arch/x86/kernel/cpu/common.c
    arch/x86/kernel/irq.c
    arch/x86/kernel/syscall_table_32.S
    arch/x86/mm/iomap_32.c
    include/linux/sched.h
    kernel/Makefile

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

03 Apr, 2009

2 commits

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
    Remove two unneeded exports and make two symbols static in fs/mpage.c
    Cleanup after commit 585d3bc06f4ca57f975a5a1f698f65a45ea66225
    Trim includes of fdtable.h
    Don't crap into descriptor table in binfmt_som
    Trim includes in binfmt_elf
    Don't mess with descriptor table in load_elf_binary()
    Get rid of indirect include of fs_struct.h
    New helper - current_umask()
    check_unsafe_exec() doesn't care about signal handlers sharing
    New locking/refcounting for fs_struct
    Take fs_struct handling to new file (fs/fs_struct.c)
    Get rid of bumping fs_struct refcount in pivot_root(2)
    Kill unsharing fs_struct in __set_personality()

    Linus Torvalds
     
  • We are wasting 2 words in signal_struct without any reason to implement
    task_pgrp_nr() and task_session_nr().

    task_session_nr() has no callers since
    2e2ba22ea4fd4bb85f0fa37c521066db6775cbef, we can remove it.

    task_pgrp_nr() is still (I believe wrongly) used in fs/autofsX and
    fs/coda.

    This patch reimplements task_pgrp_nr() via task_pgrp_nr_ns(), and kills
    __pgrp/__session and the related helpers.

    The change in drivers/char/tty_io.c is cosmetic, but hopefully makes sense
    anyway.

    Signed-off-by: Oleg Nesterov
    Acked-by: Alan Cox [tty parts]
    Cc: Cedric Le Goater
    Cc: Dave Hansen
    Cc: Eric Biederman
    Cc: Pavel Emelyanov
    Cc: Serge Hallyn
    Cc: Sukadev Bhattiprolu
    Cc: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     

01 Apr, 2009

1 commit


04 Mar, 2009

1 commit


27 Feb, 2009

1 commit

  • Impact: fix hung task with certain (non-default) rt-limit settings

    Corey Hickey reported that on using setuid to change the uid of a
    rt process, the process would be unkillable and not be running.
    This is because there was no rt runtime for that user group. Add
    in a check to see if a user can attach an rt task to its task group.
    On failure, return EINVAL, which is also returned in
    CONFIG_CGROUP_SCHED.

    Reported-by: Corey Hickey
    Signed-off-by: Dhaval Giani
    Acked-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar

    Dhaval Giani
     

11 Feb, 2009

1 commit


06 Feb, 2009

1 commit

  • Revert commit 0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f because it causes
    (arguably poorly designed) existing userspace to spend interminable
    periods closing billions of not-open file descriptors.

    We could bring this back, with some sort of opt-in tunable in /proc, which
    defaults to "off".

    Peter's alanysis follows:

    : I spent several hours trying to get to the bottom of a serious
    : performance issue that appeared on one of our servers after upgrading to
    : 2.6.28. In the end it's what could be considered a userspace bug that
    : was triggered by a change in 2.6.28. Since this might also affect other
    : people I figured I'd at least document what I found here, and maybe we
    : can even do something about it:
    :
    :
    : So, I upgraded some of debian.org's machines to 2.6.28.1 and immediately
    : the team maintaining our ftp archive complained that one of their
    : scripts that previously ran in a few minutes still hadn't even come
    : close to being done after an hour or so. Downgrading to 2.6.27 fixed
    : that.
    :
    : Turns out that script is forking a lot and something in it or python or
    : whereever closes all the file descriptors it doesn't want to pass on.
    : That is, it starts at zero and goes up to ulimit -n/RLIMIT_NOFILE and
    : closes them all with a few exceptions.
    :
    : Turns out that takes a long time when your limit -n is now 2^20 (1048576).
    :
    : With 2.6.27.* the ulimit -n was the standard 1024, but with 2.6.28 it is
    : now a thousand times that.
    :
    : 2.6.28 included a patch titled "rlimit: permit setting RLIMIT_NOFILE to
    : RLIM_INFINITY" (0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f)[1] that
    : allows, as the title implies, to set the limit for number of files to
    : infinity.
    :
    : Closer investigation showed that the broken default ulimit did not apply
    : to "system" processes (like stuff started from init). In the end I
    : could establish that all processes that passed through pam_limit at one
    : point had the bad resource limit.
    :
    : Apparently the pam library in Debian etch (4.0) initializes the limits
    : to some default values when it doesn't have any settings in limit.conf
    : to override them. Turns out that for nofiles this is RLIM_INFINITY.
    : Commenting out "case RLIMIT_NOFILE" in pam_limit.c:267 of our pam
    : package version 0.79-5 fixes that - tho I'm not sure what side effects
    : that has.
    :
    : Debian lenny (the upcoming 5.0 version) doesn't have this issue as it
    : uses a different pam (version).

    Reported-by: Peter Palfrader
    Cc: Adam Tkac
    Cc: Michael Kerrisk
    Cc: [2.6.28.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

21 Jan, 2009

1 commit


14 Jan, 2009

9 commits


11 Jan, 2009

1 commit


07 Jan, 2009

2 commits

  • …l/git/tip/linux-2.6-tip

    * 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    sched: fix section mismatch
    sched: fix double kfree in failure path
    sched: clean up arch_reinit_sched_domains()
    sched: mark sched_create_sysfs_power_savings_entries() as __init
    getrusage: RUSAGE_THREAD should return ru_utime and ru_stime
    sched: fix sched_slice()
    sched_clock: prevent scd->clock from moving backwards, take #2
    sched: sched.c declare variables before they get used

    Linus Torvalds
     
  • At the moment, the times() system call will appear to fail for a period
    shortly after boot, while the value it want to return is between -4095 and
    -1. The same thing will also happen for the time() system call on 32-bit
    platforms some time in 2106 or so.

    On some platforms, such as x86, this is unavoidable because of the system
    call ABI, but other platforms such as powerpc have a separate error
    indication from the return value, so system calls can in fact return small
    negative values without indicating an error. On those platforms,
    force_successful_syscall_return() provides a way to indicate that the
    system call return value should not be treated as an error even if it is
    in the range which would normally be taken as a negative error number.

    This adds a force_successful_syscall_return() call to the time() and
    times() system calls plus their 32-bit compat versions, so that they don't
    erroneously indicate an error on those platforms whose system call ABI has
    a separate error indication. This will not affect anything on other
    platforms.

    Joakim Tjernlund added the fix for time() and the compat versions of
    time() and times(), after I did the fix for times().

    Signed-off-by: Joakim Tjernlund
    Signed-off-by: Paul Mackerras
    Acked-by: David S. Miller
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Mackerras
     

04 Jan, 2009

1 commit


31 Dec, 2008

1 commit

  • * 'core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (63 commits)
    stacktrace: provide save_stack_trace_tsk() weak alias
    rcu: provide RCU options on non-preempt architectures too
    printk: fix discarding message when recursion_bug
    futex: clean up futex_(un)lock_pi fault handling
    "Tree RCU": scalable classic RCU implementation
    futex: rename field in futex_q to clarify single waiter semantics
    x86/swiotlb: add default swiotlb_arch_range_needs_mapping
    x86/swiotlb: add default physbus conversion
    x86: unify pci iommu setup and allow swiotlb to compile for 32 bit
    x86: add swiotlb allocation functions
    swiotlb: consolidate swiotlb info message printing
    swiotlb: support bouncing of HighMem pages
    swiotlb: factor out copy to/from device
    swiotlb: add arch hook to force mapping
    swiotlb: allow architectures to override physbusphys conversions
    swiotlb: add comment where we handle the overflow of a dma mask on 32 bit
    rcu: fix rcutorture behavior during reboot
    resources: skip sanity check of busy resources
    swiotlb: move some definitions to header
    swiotlb: allow architectures to override swiotlb pool allocation
    ...

    Fix up trivial conflicts in
    arch/x86/kernel/Makefile
    arch/x86/mm/init_32.c
    include/linux/hardirq.h
    as per Ingo's suggestions.

    Linus Torvalds
     

29 Dec, 2008

1 commit


11 Dec, 2008

1 commit


25 Nov, 2008

1 commit

  • The user_ns is moved from nsproxy to user_struct, so that a struct
    cred by itself is sufficient to determine access (which it otherwise
    would not be). Corresponding ecryptfs fixes (by David Howells) are
    here as well.

    Fix refcounting. The following rules now apply:
    1. The task pins the user struct.
    2. The user struct pins its user namespace.
    3. The user namespace pins the struct user which created it.

    User namespaces are cloned during copy_creds(). Unsharing a new user_ns
    is no longer possible. (We could re-add that, but it'll cause code
    duplication and doesn't seem useful if PAM doesn't need to clone user
    namespaces).

    When a user namespace is created, its first user (uid 0) gets empty
    keyrings and a clean group_info.

    This incorporates a previous patch by David Howells. Here
    is his original patch description:

    >I suggest adding the attached incremental patch. It makes the following
    >changes:
    >
    > (1) Provides a current_user_ns() macro to wrap accesses to current's user
    > namespace.
    >
    > (2) Fixes eCryptFS.
    >
    > (3) Renames create_new_userns() to create_user_ns() to be more consistent
    > with the other associated functions and because the 'new' in the name is
    > superfluous.
    >
    > (4) Moves the argument and permission checks made for CLONE_NEWUSER to the
    > beginning of do_fork() so that they're done prior to making any attempts
    > at allocation.
    >
    > (5) Calls create_user_ns() after prepare_creds(), and gives it the new creds
    > to fill in rather than have it return the new root user. I don't imagine
    > the new root user being used for anything other than filling in a cred
    > struct.
    >
    > This also permits me to get rid of a get_uid() and a free_uid(), as the
    > reference the creds were holding on the old user_struct can just be
    > transferred to the new namespace's creator pointer.
    >
    > (6) Makes create_user_ns() reset the UIDs and GIDs of the creds under
    > preparation rather than doing it in copy_creds().
    >
    >David

    >Signed-off-by: David Howells

    Changelog:
    Oct 20: integrate dhowells comments
    1. leave thread_keyring alone
    2. use current_user_ns() in set_user()

    Signed-off-by: Serge Hallyn

    Serge Hallyn
     

17 Nov, 2008

1 commit


14 Nov, 2008

5 commits

  • Inaugurate copy-on-write credentials management. This uses RCU to manage the
    credentials pointer in the task_struct with respect to accesses by other tasks.
    A process may only modify its own credentials, and so does not need locking to
    access or modify its own credentials.

    A mutex (cred_replace_mutex) is added to the task_struct to control the effect
    of PTRACE_ATTACHED on credential calculations, particularly with respect to
    execve().

    With this patch, the contents of an active credentials struct may not be
    changed directly; rather a new set of credentials must be prepared, modified
    and committed using something like the following sequence of events:

    struct cred *new = prepare_creds();
    int ret = blah(new);
    if (ret < 0) {
    abort_creds(new);
    return ret;
    }
    return commit_creds(new);

    There are some exceptions to this rule: the keyrings pointed to by the active
    credentials may be instantiated - keyrings violate the COW rule as managing
    COW keyrings is tricky, given that it is possible for a task to directly alter
    the keys in a keyring in use by another task.

    To help enforce this, various pointers to sets of credentials, such as those in
    the task_struct, are declared const. The purpose of this is compile-time
    discouragement of altering credentials through those pointers. Once a set of
    credentials has been made public through one of these pointers, it may not be
    modified, except under special circumstances:

    (1) Its reference count may incremented and decremented.

    (2) The keyrings to which it points may be modified, but not replaced.

    The only safe way to modify anything else is to create a replacement and commit
    using the functions described in Documentation/credentials.txt (which will be
    added by a later patch).

    This patch and the preceding patches have been tested with the LTP SELinux
    testsuite.

    This patch makes several logical sets of alteration:

    (1) execve().

    This now prepares and commits credentials in various places in the
    security code rather than altering the current creds directly.

    (2) Temporary credential overrides.

    do_coredump() and sys_faccessat() now prepare their own credentials and
    temporarily override the ones currently on the acting thread, whilst
    preventing interference from other threads by holding cred_replace_mutex
    on the thread being dumped.

    This will be replaced in a future patch by something that hands down the
    credentials directly to the functions being called, rather than altering
    the task's objective credentials.

    (3) LSM interface.

    A number of functions have been changed, added or removed:

    (*) security_capset_check(), ->capset_check()
    (*) security_capset_set(), ->capset_set()

    Removed in favour of security_capset().

    (*) security_capset(), ->capset()

    New. This is passed a pointer to the new creds, a pointer to the old
    creds and the proposed capability sets. It should fill in the new
    creds or return an error. All pointers, barring the pointer to the
    new creds, are now const.

    (*) security_bprm_apply_creds(), ->bprm_apply_creds()

    Changed; now returns a value, which will cause the process to be
    killed if it's an error.

    (*) security_task_alloc(), ->task_alloc_security()

    Removed in favour of security_prepare_creds().

    (*) security_cred_free(), ->cred_free()

    New. Free security data attached to cred->security.

    (*) security_prepare_creds(), ->cred_prepare()

    New. Duplicate any security data attached to cred->security.

    (*) security_commit_creds(), ->cred_commit()

    New. Apply any security effects for the upcoming installation of new
    security by commit_creds().

    (*) security_task_post_setuid(), ->task_post_setuid()

    Removed in favour of security_task_fix_setuid().

    (*) security_task_fix_setuid(), ->task_fix_setuid()

    Fix up the proposed new credentials for setuid(). This is used by
    cap_set_fix_setuid() to implicitly adjust capabilities in line with
    setuid() changes. Changes are made to the new credentials, rather
    than the task itself as in security_task_post_setuid().

    (*) security_task_reparent_to_init(), ->task_reparent_to_init()

    Removed. Instead the task being reparented to init is referred
    directly to init's credentials.

    NOTE! This results in the loss of some state: SELinux's osid no
    longer records the sid of the thread that forked it.

    (*) security_key_alloc(), ->key_alloc()
    (*) security_key_permission(), ->key_permission()

    Changed. These now take cred pointers rather than task pointers to
    refer to the security context.

    (4) sys_capset().

    This has been simplified and uses less locking. The LSM functions it
    calls have been merged.

    (5) reparent_to_kthreadd().

    This gives the current thread the same credentials as init by simply using
    commit_thread() to point that way.

    (6) __sigqueue_alloc() and switch_uid()

    __sigqueue_alloc() can't stop the target task from changing its creds
    beneath it, so this function gets a reference to the currently applicable
    user_struct which it then passes into the sigqueue struct it returns if
    successful.

    switch_uid() is now called from commit_creds(), and possibly should be
    folded into that. commit_creds() should take care of protecting
    __sigqueue_alloc().

    (7) [sg]et[ug]id() and co and [sg]et_current_groups.

    The set functions now all use prepare_creds(), commit_creds() and
    abort_creds() to build and check a new set of credentials before applying
    it.

    security_task_set[ug]id() is called inside the prepared section. This
    guarantees that nothing else will affect the creds until we've finished.

    The calling of set_dumpable() has been moved into commit_creds().

    Much of the functionality of set_user() has been moved into
    commit_creds().

    The get functions all simply access the data directly.

    (8) security_task_prctl() and cap_task_prctl().

    security_task_prctl() has been modified to return -ENOSYS if it doesn't
    want to handle a function, or otherwise return the return value directly
    rather than through an argument.

    Additionally, cap_task_prctl() now prepares a new set of credentials, even
    if it doesn't end up using it.

    (9) Keyrings.

    A number of changes have been made to the keyrings code:

    (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
    all been dropped and built in to the credentials functions directly.
    They may want separating out again later.

    (b) key_alloc() and search_process_keyrings() now take a cred pointer
    rather than a task pointer to specify the security context.

    (c) copy_creds() gives a new thread within the same thread group a new
    thread keyring if its parent had one, otherwise it discards the thread
    keyring.

    (d) The authorisation key now points directly to the credentials to extend
    the search into rather pointing to the task that carries them.

    (e) Installing thread, process or session keyrings causes a new set of
    credentials to be created, even though it's not strictly necessary for
    process or session keyrings (they're shared).

    (10) Usermode helper.

    The usermode helper code now carries a cred struct pointer in its
    subprocess_info struct instead of a new session keyring pointer. This set
    of credentials is derived from init_cred and installed on the new process
    after it has been cloned.

    call_usermodehelper_setup() allocates the new credentials and
    call_usermodehelper_freeinfo() discards them if they haven't been used. A
    special cred function (prepare_usermodeinfo_creds()) is provided
    specifically for call_usermodehelper_setup() to call.

    call_usermodehelper_setkeys() adjusts the credentials to sport the
    supplied keyring as the new session keyring.

    (11) SELinux.

    SELinux has a number of changes, in addition to those to support the LSM
    interface changes mentioned above:

    (a) selinux_setprocattr() no longer does its check for whether the
    current ptracer can access processes with the new SID inside the lock
    that covers getting the ptracer's SID. Whilst this lock ensures that
    the check is done with the ptracer pinned, the result is only valid
    until the lock is released, so there's no point doing it inside the
    lock.

    (12) is_single_threaded().

    This function has been extracted from selinux_setprocattr() and put into
    a file of its own in the lib/ directory as join_session_keyring() now
    wants to use it too.

    The code in SELinux just checked to see whether a task shared mm_structs
    with other tasks (CLONE_VM), but that isn't good enough. We really want
    to know if they're part of the same thread group (CLONE_THREAD).

    (13) nfsd.

    The NFS server daemon now has to use the COW credentials to set the
    credentials it is going to use. It really needs to pass the credentials
    down to the functions it calls, but it can't do that until other patches
    in this series have been applied.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Signed-off-by: James Morris

    David Howells
     
  • Use RCU to access another task's creds and to release a task's own creds.
    This means that it will be possible for the credentials of a task to be
    replaced without another task (a) requiring a full lock to read them, and (b)
    seeing deallocated memory.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Wrap current->cred and a few other accessors to hide their actual
    implementation.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Separate the task security context from task_struct. At this point, the
    security data is temporarily embedded in the task_struct with two pointers
    pointing to it.

    Note that the Alpha arch is altered as it refers to (E)UID and (E)GID in
    entry.S via asm-offsets.

    With comment fixes Signed-off-by: Marc Dionne

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Wrap access to task credentials so that they can be separated more easily from
    the task_struct during the introduction of COW creds.

    Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().

    Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
    sense to use RCU directly rather than a convenient wrapper; these will be
    addressed by later patches.

    Signed-off-by: David Howells
    Reviewed-by: James Morris
    Acked-by: Serge Hallyn
    Cc: Al Viro
    Cc: linux-audit@redhat.com
    Cc: containers@lists.linux-foundation.org
    Cc: linux-mm@kvack.org
    Signed-off-by: James Morris

    David Howells
     

22 Oct, 2008

1 commit


20 Oct, 2008

1 commit


18 Oct, 2008

1 commit


17 Oct, 2008

2 commits

  • utsname() is quite expensive to calculate. Cache it in a local.

    text data bss dec hex filename
    before: 11136 720 16 11872 2e60 kernel/sys.o
    after: 11096 720 16 11832 2e38 kernel/sys.o

    Acked-by: Vegard Nossum
    Cc: "Eric W. Biederman"
    Acked-by: "Serge E. Hallyn"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • On sethostname() and setdomainname(), previous information may be retained
    if it was longer than than the new hostname/domainname.

    This can be demonstrated trivially by calling sethostname() first with a
    long name, then with a short name, and then calling uname() to retrieve
    the full buffer that contains the hostname (and possibly parts of the old
    hostname), one just has to look past the terminating zero.

    I don't know if we should really care that much (hence the RFC); the only
    scenarios I can possibly think of is administrator putting something
    sensitive in the hostname (or domain name) by accident, and changing it
    back will not undo the mistake entirely, though it's not like we can
    recover gracefully from "rm -rf /" either... The other scenario is
    namespaces (CLONE_NEWUTS) where some information may be unintentionally
    "inherited" from the previous namespace (a program wants to hide the
    original name and does clone + sethostname, but some information is still
    left).

    I think the patch may be defended on grounds of the principle of least
    surprise. But I am not adamant :-)

    (I guess the question now is whether userspace should be able to
    write embedded NULs into the buffer or not...)

    At least the observation has been made and the patch has been presented.

    Signed-off-by: Vegard Nossum
    Cc: "Eric W. Biederman"
    Cc: "Serge E. Hallyn"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vegard Nossum