10 Oct, 2018

1 commit

  • commit ffc4c92227db5699493e43eb140b4cb5904c30ff upstream.

    Commit 786534b92f3c introduced a regression that caused listxattr to
    return the POSIX ACL attribute names even though sysfs doesn't support
    POSIX ACLs. This happens because simple_xattr_list checks for NULL
    i_acl / i_default_acl, but inode_init_always initializes those fields
    to ACL_NOT_CACHED ((void *)-1). For example:
    $ getfattr -m- -d /sys
    /sys: system.posix_acl_access: Operation not supported
    /sys: system.posix_acl_default: Operation not supported
    Fix this in simple_xattr_list by checking if the filesystem supports POSIX ACLs.

    Fixes: 786534b92f3c ("tmpfs: listxattr should include POSIX ACL xattrs")
    Reported-by: Marc Aurèle La France
    Tested-by: Marc Aurèle La France
    Signed-off-by: Andreas Gruenbacher
    Cc: stable@vger.kernel.org # v4.5+
    Signed-off-by: Al Viro
    Signed-off-by: Greg Kroah-Hartman

    Andreas Gruenbacher
     

10 Sep, 2018

1 commit

  • commit 82c9a927bc5df6e06b72d206d24a9d10cced4eb5 upstream.

    When running in a container with a user namespace, if you call getxattr
    with name = "system.posix_acl_access" and size % 8 != 4, then getxattr
    silently skips the user namespace fixup that it normally does resulting in
    un-fixed-up data being returned.
    This is caused by posix_acl_fix_xattr_to_user() being passed the total
    buffer size and not the actual size of the xattr as returned by
    vfs_getxattr().
    This commit passes the actual length of the xattr as returned by
    vfs_getxattr() down.

    A reproducer for the issue is:

    touch acl_posix

    setfacl -m user:0:rwx acl_posix

    and the compile:

    #define _GNU_SOURCE
    #include
    #include
    #include
    #include
    #include
    #include
    #include

    /* Run in user namespace with nsuid 0 mapped to uid != 0 on the host. */
    int main(int argc, void **argv)
    {
    ssize_t ret1, ret2;
    char buf1[128], buf2[132];
    int fret = EXIT_SUCCESS;
    char *file;

    if (argc < 2) {
    fprintf(stderr,
    "Please specify a file with "
    "\"system.posix_acl_access\" permissions set\n");
    _exit(EXIT_FAILURE);
    }
    file = argv[1];

    ret1 = getxattr(file, "system.posix_acl_access",
    buf1, sizeof(buf1));
    if (ret1 < 0) {
    fprintf(stderr, "%s - Failed to retrieve "
    "\"system.posix_acl_access\" "
    "from \"%s\"\n", strerror(errno), file);
    _exit(EXIT_FAILURE);
    }

    ret2 = getxattr(file, "system.posix_acl_access",
    buf2, sizeof(buf2));
    if (ret2 < 0) {
    fprintf(stderr, "%s - Failed to retrieve "
    "\"system.posix_acl_access\" "
    "from \"%s\"\n", strerror(errno), file);
    _exit(EXIT_FAILURE);
    }

    if (ret1 != ret2) {
    fprintf(stderr, "The value of \"system.posix_acl_"
    "access\" for file \"%s\" changed "
    "between two successive calls\n", file);
    _exit(EXIT_FAILURE);
    }

    for (ssize_t i = 0; i < ret2; i++) {
    if (buf1[i] == buf2[i])
    continue;

    fprintf(stderr,
    "Unexpected different in byte %zd: "
    "%02x != %02x\n", i, buf1[i], buf2[i]);
    fret = EXIT_FAILURE;
    }

    if (fret == EXIT_SUCCESS)
    fprintf(stderr, "Test passed\n");
    else
    fprintf(stderr, "Test failed\n");

    _exit(fret);
    }
    and run:

    ./tester acl_posix

    On a non-fixed up kernel this should return something like:

    root@c1:/# ./t
    Unexpected different in byte 16: ffffffa0 != 00
    Unexpected different in byte 17: ffffff86 != 00
    Unexpected different in byte 18: 01 != 00

    and on a fixed kernel:

    root@c1:~# ./t
    Test passed

    Cc: stable@vger.kernel.org
    Fixes: 2f6f0654ab61 ("userns: Convert vfs posix_acl support to use kuids and kgids")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199945
    Reported-by: Colin Watson
    Signed-off-by: Christian Brauner
    Acked-by: Serge Hallyn
    Signed-off-by: Eric W. Biederman
    Signed-off-by: Greg Kroah-Hartman

    Christian Brauner
     

04 Oct, 2017

1 commit

  • security_inode_getsecurity() provides the text string value
    of a security attribute. It does not provide a "secctx".
    The code in xattr_getsecurity() that calls security_inode_getsecurity()
    and then calls security_release_secctx() happened to work because
    SElinux and Smack treat the attribute and the secctx the same way.
    It fails for cap_inode_getsecurity(), because that module has no
    secctx that ever needs releasing. It turns out that Smack is the
    one that's doing things wrong by not allocating memory when instructed
    to do so by the "alloc" parameter.

    The fix is simple enough. Change the security_release_secctx() to
    kfree() because it isn't a secctx being returned by
    security_inode_getsecurity(). Change Smack to allocate the string when
    told to do so.

    Note: this also fixes memory leaks for LSMs which implement
    inode_getsecurity but not release_secctx, such as capabilities.

    Signed-off-by: Casey Schaufler
    Reported-by: Konstantin Khlebnikov
    Cc: stable@vger.kernel.org
    Signed-off-by: James Morris

    Casey Schaufler
     

14 Sep, 2017

1 commit

  • Pull overlayfs updates from Miklos Szeredi:
    "This fixes d_ino correctness in readdir, which brings overlayfs on par
    with normal filesystems regarding inode number semantics, as long as
    all layers are on the same filesystem.

    There are also some bug fixes, one in particular (random ioctl's
    shouldn't be able to modify lower layers) that touches some vfs code,
    but of course no-op for non-overlay fs"

    * 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
    ovl: fix false positive ESTALE on lookup
    ovl: don't allow writing ioctl on lower layer
    ovl: fix relatime for directories
    vfs: add flags to d_real()
    ovl: cleanup d_real for negative
    ovl: constant d_ino for non-merge dirs
    ovl: constant d_ino across copy up
    ovl: fix readdir error value
    ovl: check snprintf return

    Linus Torvalds
     

05 Sep, 2017

1 commit

  • Problem with ioctl() is that it's a file operation, yet often used as an
    inode operation (i.e. modify the inode despite the file being opened for
    read-only).

    mnt_want_write_file() is used by filesystems in such cases to get write
    access on an arbitrary open file.

    Since overlayfs lets filesystems do all file operations, including ioctl,
    this can lead to mnt_want_write_file() returning OK for a lower file and
    modification of that lower file.

    This patch prevents modification by checking if the file is from an
    overlayfs lower layer and returning EPERM in that case.

    Need to introduce a mnt_want_write_file_path() variant that still does the
    old thing for inode operations that can do the copy up + modification
    correctly in such cases (fchown, fsetxattr, fremovexattr).

    This does not address the correctness of such ioctls on overlayfs (the
    correct way would be to copy up and attempt to perform ioctl on upper
    file).

    In theory this could be a regression. We very much hope that nobody is
    relying on such a hack in any sane setup.

    While this patch meddles in VFS code, it has no effect on non-overlayfs
    filesystems.

    Reported-by: "zhangyi (F)"
    Signed-off-by: Miklos Szeredi

    Miklos Szeredi
     

02 Sep, 2017

1 commit

  • Root in a non-initial user ns cannot be trusted to write a traditional
    security.capability xattr. If it were allowed to do so, then any
    unprivileged user on the host could map his own uid to root in a private
    namespace, write the xattr, and execute the file with privilege on the
    host.

    However supporting file capabilities in a user namespace is very
    desirable. Not doing so means that any programs designed to run with
    limited privilege must continue to support other methods of gaining and
    dropping privilege. For instance a program installer must detect
    whether file capabilities can be assigned, and assign them if so but set
    setuid-root otherwise. The program in turn must know how to drop
    partial capabilities, and do so only if setuid-root.

    This patch introduces v3 of the security.capability xattr. It builds a
    vfs_ns_cap_data struct by appending a uid_t rootid to struct
    vfs_cap_data. This is the absolute uid_t (that is, the uid_t in user
    namespace which mounted the filesystem, usually init_user_ns) of the
    root id in whose namespaces the file capabilities may take effect.

    When a task asks to write a v2 security.capability xattr, if it is
    privileged with respect to the userns which mounted the filesystem, then
    nothing should change. Otherwise, the kernel will transparently rewrite
    the xattr as a v3 with the appropriate rootid. This is done during the
    execution of setxattr() to catch user-space-initiated capability writes.
    Subsequently, any task executing the file which has the noted kuid as
    its root uid, or which is in a descendent user_ns of such a user_ns,
    will run the file with capabilities.

    Similarly when asking to read file capabilities, a v3 capability will
    be presented as v2 if it applies to the caller's namespace.

    If a task writes a v3 security.capability, then it can provide a uid for
    the xattr so long as the uid is valid in its own user namespace, and it
    is privileged with CAP_SETFCAP over its namespace. The kernel will
    translate that rootid to an absolute uid, and write that to disk. After
    this, a task in the writer's namespace will not be able to use those
    capabilities (unless rootid was 0), but a task in a namespace where the
    given uid is root will.

    Only a single security.capability xattr may exist at a time for a given
    file. A task may overwrite an existing xattr so long as it is
    privileged over the inode. Note this is a departure from previous
    semantics, which required privilege to remove a security.capability
    xattr. This check can be re-added if deemed useful.

    This allows a simple setxattr to work, allows tar/untar to work, and
    allows us to tar in one namespace and untar in another while preserving
    the capability, without risking leaking privilege into a parent
    namespace.

    Example using tar:

    $ cp /bin/sleep sleepx
    $ mkdir b1 b2
    $ lxc-usernsexec -m b:0:100000:1 -m b:1:$(id -u):1 -- chown 0:0 b1
    $ lxc-usernsexec -m b:0:100001:1 -m b:1:$(id -u):1 -- chown 0:0 b2
    $ lxc-usernsexec -m b:0:100000:1000 -- tar --xattrs-include=security.capability --xattrs -cf b1/sleepx.tar sleepx
    $ lxc-usernsexec -m b:0:100001:1000 -- tar --xattrs-include=security.capability --xattrs -C b2 -xf b1/sleepx.tar
    $ lxc-usernsexec -m b:0:100001:1000 -- getcap b2/sleepx
    b2/sleepx = cap_sys_admin+ep
    # /opt/ltp/testcases/bin/getv3xattr b2/sleepx
    v3 xattr, rootid is 100001

    A patch to linux-test-project adding a new set of tests for this
    functionality is in the nsfscaps branch at github.com/hallyn/ltp

    Changelog:
    Nov 02 2016: fix invalid check at refuse_fcap_overwrite()
    Nov 07 2016: convert rootid from and to fs user_ns
    (From ebiederm: mar 28 2017)
    commoncap.c: fix typos - s/v4/v3
    get_vfs_caps_from_disk: clarify the fs_ns root access check
    nsfscaps: change the code split for cap_inode_setxattr()
    Apr 09 2017:
    don't return v3 cap for caps owned by current root.
    return a v2 cap for a true v2 cap in non-init ns
    Apr 18 2017:
    . Change the flow of fscap writing to support s_user_ns writing.
    . Remove refuse_fcap_overwrite(). The value of the previous
    xattr doesn't matter.
    Apr 24 2017:
    . incorporate Eric's incremental diff
    . move cap_convert_nscap to setxattr and simplify its usage
    May 8, 2017:
    . fix leaking dentry refcount in cap_inode_getsecurity

    Signed-off-by: Serge Hallyn
    Signed-off-by: Eric W. Biederman

    Serge E. Hallyn
     

09 May, 2017

2 commits

  • There are many code paths opencoding kvmalloc. Let's use the helper
    instead. The main difference to kvmalloc is that those users are
    usually not considering all the aspects of the memory allocator. E.g.
    allocation requests
    Reviewed-by: Boris Ostrovsky # Xen bits
    Acked-by: Kees Cook
    Acked-by: Vlastimil Babka
    Acked-by: Andreas Dilger # Lustre
    Acked-by: Christian Borntraeger # KVM/s390
    Acked-by: Dan Williams # nvdim
    Acked-by: David Sterba # btrfs
    Acked-by: Ilya Dryomov # Ceph
    Acked-by: Tariq Toukan # mlx4
    Acked-by: Leon Romanovsky # mlx5
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Cc: Herbert Xu
    Cc: Anton Vorontsov
    Cc: Colin Cross
    Cc: Tony Luck
    Cc: "Rafael J. Wysocki"
    Cc: Ben Skeggs
    Cc: Kent Overstreet
    Cc: Santosh Raspatur
    Cc: Hariprasad S
    Cc: Yishai Hadas
    Cc: Oleg Drokin
    Cc: "Yan, Zheng"
    Cc: Alexander Viro
    Cc: Alexei Starovoitov
    Cc: Eric Dumazet
    Cc: David Miller
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Hocko
     
  • getxattr uses vmalloc to allocate memory if kzalloc fails. This is
    filled by vfs_getxattr and then copied to the userspace. vmalloc,
    however, doesn't zero out the memory so if the specific implementation
    of the xattr handler is sloppy we can theoretically expose a kernel
    memory. There is no real sign this is really the case but let's make
    sure this will not happen and use vzalloc instead.

    Fixes: 779302e67835 ("fs/xattr.c:getxattr(): improve handling of allocation failures")
    Link: http://lkml.kernel.org/r/20170306103327.2766-1-mhocko@kernel.org
    Acked-by: Kees Cook
    Reported-by: Vlastimil Babka
    Signed-off-by: Michal Hocko
    Cc: [3.6+]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Hocko
     

25 Dec, 2016

1 commit


17 Nov, 2016

1 commit

  • The IOP_XATTR flag is set on sockfs because sockfs supports getting the
    "system.sockprotoname" xattr. Since commit 6c6ef9f2, this flag is checked for
    setxattr support as well. This is wrong on sockfs because security xattr
    support there is supposed to be provided by security_inode_setsecurity. The
    smack security module relies on socket labels (xattrs).

    Fix this by adding a security xattr handler on sockfs that returns
    -EAGAIN, and by checking for -EAGAIN in setxattr.

    We cannot simply check for -EOPNOTSUPP in setxattr because there are
    filesystems that neither have direct security xattr support nor support
    via security_inode_setsecurity. A more proper fix might be to move the
    call to security_inode_setsecurity into sockfs, but it's not clear to me
    if that is safe: we would end up calling security_inode_post_setxattr after
    that as well.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     

08 Oct, 2016

7 commits

  • These inode operations are no longer used; remove them.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • All filesystems that support xattrs by now do so via xattr handlers.
    They all define sb->s_xattr, and their getxattr, setxattr, and
    removexattr inode operations use the generic inode operations. On
    filesystems that don't support xattrs, the xattr inode operations are
    all NULL, and sb->s_xattr is also NULL.

    This means that we can remove the getxattr, setxattr, and removexattr
    inode operations and directly call the generic handlers, or better,
    inline expand those handlers into fs/xattr.c.

    Filesystems that do not support xattrs on some inodes should clear the
    IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
    have checks to disable xattrs on some inodes in the ->list, ->get, and
    ->set xattr handler operations instead.) The IOP_XATTR flag is
    automatically cleared in inodes of filesystems that don't have xattr
    support.

    In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
    check for symlinks to orangefs_inode_getxattr to preserve the current,
    weird behavior; that check may not be necessary though.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • When an inode doesn't support xattrs, turn listxattr off as well.

    (When xattrs are "turned off", the VFS still passes security xattr
    operations through to security modules, which can still expose inode
    security labels that way.)

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • Right now, various places in the kernel check for the existence of
    getxattr, setxattr, and removexattr inode operations and directly call
    those operations. Switch to helper functions and test for the IOP_XATTR
    flag instead.

    Signed-off-by: Andreas Gruenbacher
    Acked-by: James Morris
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • With this change, all the xattr handler based operations will produce an
    -EIO result for bad inodes, and we no longer only depend on inode->i_op
    to be set to bad_inode_ops.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • The IOP_XATTR inode operations flag in inode->i_opflags indicates that
    the inode has xattr support. The flag is automatically set by
    new_inode() on filesystems with xattr support (where sb->s_xattr is
    defined), and cleared otherwise. Filesystems can explicitly clear it
    for inodes that should not have xattr support.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     

07 Oct, 2016

1 commit


06 Jul, 2016

1 commit

  • When a filesystem outside of init_user_ns is mounted it could have
    uids and gids stored in it that do not map to init_user_ns.

    The plan is to allow those filesystems to set i_uid to INVALID_UID and
    i_gid to INVALID_GID for unmapped uids and gids and then to handle
    that strange case in the vfs to ensure there is consistent robust
    handling of the weirdness.

    Upon a careful review of the vfs and filesystems about the only case
    where there is any possibility of confusion or trouble is when the
    inode is written back to disk. In that case filesystems typically
    read the inode->i_uid and inode->i_gid and write them to disk even
    when just an inode timestamp is being updated.

    Which leads to a rule that is very simple to implement and understand
    inodes whose i_uid or i_gid is not valid may not be written.

    In dealing with access times this means treat those inodes as if the
    inode flag S_NOATIME was set. Reads of the inodes appear safe and
    useful, but any write or modification is disallowed. The only inode
    write that is allowed is a chown that sets the uid and gid on the
    inode to valid values. After such a chown the inode is normal and may
    be treated as such.

    Denying all writes to inodes with uids or gids unknown to the vfs also
    prevents several oddball cases where corruption would have occurred
    because the vfs does not have complete information.

    One problem case that is prevented is attempting to use the gid of a
    directory for new inodes where the directories sgid bit is set but the
    directories gid is not mapped.

    Another problem case avoided is attempting to update the evm hash
    after setxattr, removexattr, and setattr. As the evm hash includeds
    the inode->i_uid or inode->i_gid not knowning the uid or gid prevents
    a correct evm hash from being computed. evm hash verification also
    fails when i_uid or i_gid is unknown but that is essentially harmless
    as it does not cause filesystem corruption.

    Acked-by: Seth Forshee
    Signed-off-by: "Eric W. Biederman"

    Eric W. Biederman
     

28 May, 2016

2 commits

  • smack ->d_instantiate() uses ->setxattr(), so to be able to call it before
    we'd hashed the new dentry and attached it to inode, we need ->setxattr()
    instances getting the inode as an explicit argument rather than obtaining
    it from dentry.

    Similar change for ->getxattr() had been done in commit ce23e64. Unlike
    ->getxattr() (which is used by both selinux and smack instances of
    ->d_instantiate()) ->setxattr() is used only by smack one and unfortunately
    it got missed back then.

    Reported-by: Seung-Woo Kim
    Tested-by: Casey Schaufler
    Signed-off-by: Al Viro

    Al Viro
     
  • preparation for similar switch in ->setxattr() (see the next commit for
    rationale).

    Signed-off-by: Al Viro

    Al Viro
     

26 May, 2016

2 commits


11 Apr, 2016

2 commits


20 Feb, 2016

1 commit


23 Jan, 2016

1 commit

  • parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested},
    inode_foo(inode) being mutex_foo(&inode->i_mutex).

    Please, use those for access to ->i_mutex; over the coming cycle
    ->i_mutex will become rwsem, with ->lookup() done with it held
    only shared.

    Signed-off-by: Al Viro

    Al Viro
     

13 Jan, 2016

1 commit

  • Pull misc vfs updates from Al Viro:
    "All kinds of stuff. That probably should've been 5 or 6 separate
    branches, but by the time I'd realized how large and mixed that bag
    had become it had been too close to -final to play with rebasing.

    Some fs/namei.c cleanups there, memdup_user_nul() introduction and
    switching open-coded instances, burying long-dead code, whack-a-mole
    of various kinds, several new helpers for ->llseek(), assorted
    cleanups and fixes from various people, etc.

    One piece probably deserves special mention - Neil's
    lookup_one_len_unlocked(). Similar to lookup_one_len(), but gets
    called without ->i_mutex and tries to avoid ever taking it. That, of
    course, means that it's not useful for any directory modifications,
    but things like getting inode attributes in nfds readdirplus are fine
    with that. I really should've asked for moratorium on lookup-related
    changes this cycle, but since I hadn't done that early enough... I
    *am* asking for that for the coming cycle, though - I'm going to try
    and get conversion of i_mutex to rwsem with ->lookup() done under lock
    taken shared.

    There will be a patch closer to the end of the window, along the lines
    of the one Linus had posted last May - mechanical conversion of
    ->i_mutex accesses to inode_lock()/inode_unlock()/inode_trylock()/
    inode_is_locked()/inode_lock_nested(). To quote Linus back then:

    -----
    | This is an automated patch using
    |
    | sed 's/mutex_lock(&\(.*\)->i_mutex)/inode_lock(\1)/'
    | sed 's/mutex_unlock(&\(.*\)->i_mutex)/inode_unlock(\1)/'
    | sed 's/mutex_lock_nested(&\(.*\)->i_mutex,[ ]*I_MUTEX_\([A-Z0-9_]*\))/inode_lock_nested(\1, I_MUTEX_\2)/'
    | sed 's/mutex_is_locked(&\(.*\)->i_mutex)/inode_is_locked(\1)/'
    | sed 's/mutex_trylock(&\(.*\)->i_mutex)/inode_trylock(\1)/'
    |
    | with a very few manual fixups
    -----

    I'm going to send that once the ->i_mutex-affecting stuff in -next
    gets mostly merged (or when Linus says he's about to stop taking
    merges)"

    * 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (63 commits)
    nfsd: don't hold i_mutex over userspace upcalls
    fs:affs:Replace time_t with time64_t
    fs/9p: use fscache mutex rather than spinlock
    proc: add a reschedule point in proc_readfd_common()
    logfs: constify logfs_block_ops structures
    fcntl: allow to set O_DIRECT flag on pipe
    fs: __generic_file_splice_read retry lookup on AOP_TRUNCATED_PAGE
    fs: xattr: Use kvfree()
    [s390] page_to_phys() always returns a multiple of PAGE_SIZE
    nbd: use ->compat_ioctl()
    fs: use block_device name vsprintf helper
    lib/vsprintf: add %*pg format specifier
    fs: use gendisk->disk_name where possible
    poll: plug an unused argument to do_poll
    amdkfd: don't open-code memdup_user()
    cdrom: don't open-code memdup_user()
    rsxx: don't open-code memdup_user()
    mtip32xx: don't open-code memdup_user()
    [um] mconsole: don't open-code memdup_user_nul()
    [um] hostaudio: don't open-code memdup_user()
    ...

    Linus Torvalds
     

09 Jan, 2016

1 commit


14 Dec, 2015

2 commits


07 Dec, 2015

4 commits

  • When a file on tmpfs has an ACL or a Default ACL, listxattr should include the
    corresponding xattr name.

    Signed-off-by: Andreas Gruenbacher
    Reviewed-by: James Morris
    Cc: Hugh Dickins
    Cc: linux-mm@kvack.org
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • Use the VFS xattr handler infrastructure and get rid of similar code in
    the filesystem. For implementing shmem_xattr_handler_set, we need a
    version of simple_xattr_set which removes the attribute when value is
    NULL. Use this to implement kernfs_iop_removexattr as well.

    Signed-off-by: Andreas Gruenbacher
    Reviewed-by: James Morris
    Cc: Hugh Dickins
    Cc: linux-mm@kvack.org
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • Add an additional "name" field to struct xattr_handler. When the name
    is set, the handler matches attributes with exactly that name. When the
    prefix is set instead, the handler matches attributes with the given
    prefix and with a non-empty suffix.

    This patch should avoid bugs like the one fixed in commit c361016a in
    the future.

    Signed-off-by: Andreas Gruenbacher
    Reviewed-by: James Morris
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • This function was only briefly used in security/integrity/evm, between
    commits 66dbc325 and 15647eb3.

    Signed-off-by: Andreas Gruenbacher
    Reviewed-by: James Morris
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     

14 Nov, 2015

2 commits

  • Now that the xattr handler is passed to the xattr handler operations, we
    can use the same get and set operations for the user, trusted, and security
    xattr namespaces. In those namespaces, we can access the full attribute
    name by "reattaching" the name prefix the vfs has skipped for us. Add a
    xattr_full_name helper to make this obvious in the code.

    For the "system.posix_acl_access" and "system.posix_acl_default"
    attributes, handler->prefix is the full attribute name; the suffix is the
    empty string.

    Signed-off-by: Andreas Gruenbacher
    Cc: Eric Van Hensbergen
    Cc: Ron Minnich
    Cc: Latchesar Ionkov
    Cc: v9fs-developer@lists.sourceforge.net
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • The xattr_handler operations are currently all passed a file system
    specific flags value which the operations can use to disambiguate between
    different handlers; some file systems use that to distinguish the xattr
    namespace, for example. In some oprations, it would be useful to also have
    access to the handler prefix. To allow that, pass a pointer to the handler
    to operations instead of the flags value alone.

    Signed-off-by: Andreas Gruenbacher
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     

22 May, 2015

1 commit

  • EVM needs to be atomically updated when removing xattrs.
    Otherwise concurrent EVM verification may fail in between.
    This patch fixes by moving i_mutex unlocking after calling
    EVM hook. fsnotify_xattr() is also now called while locked
    the same way as it is done in __vfs_setxattr_noperm.

    Changelog:
    - remove unused 'inode' variable.

    Signed-off-by: Dmitry Kasatkin
    Signed-off-by: Mimi Zohar

    Dmitry Kasatkin
     

20 Nov, 2014

1 commit

  • ... for situations when we don't have any candidate in pathnames - basically,
    in descriptor-based syscalls.

    [Folded the build fix for !CONFIG_AUDITSYSCALL configs from Chen Gang]

    Signed-off-by: Al Viro

    Al Viro
     

13 Oct, 2014

1 commit

  • The following pairs of system calls dealing with extended attributes only
    differ in their behavior on whether the symbolic link is followed (when
    the named file is a symbolic link):

    - setxattr() and lsetxattr()
    - getxattr() and lgetxattr()
    - listxattr() and llistxattr()
    - removexattr() and lremovexattr()

    Despite this, the implementations all had duplicated code, so this commit
    redirects each of the above pairs of system calls to a corresponding
    function to which different lookup flags (LOOKUP_FOLLOW or 0) are passed.

    For me this reduced the stripped size of xattr.o from 8824 to 8248 bytes.

    Signed-off-by: Eric Biggers
    Signed-off-by: Al Viro

    Eric Biggers