31 Jul, 2020

3 commits


14 May, 2020

1 commit

  • This makes it possible to use utimensat on an O_PATH file (including
    symlinks).

    It supersedes the nonstandard utimensat(fd, NULL, ...) form.

    Cc: linux-api@vger.kernel.org
    Cc: linux-man@vger.kernel.org
    Signed-off-by: Miklos Szeredi
    Reviewed-by: Christoph Hellwig

    Miklos Szeredi
     

09 Dec, 2019

1 commit

  • Push clamping timestamps into notify_change(), so in-kernel
    callers like nfsd and overlayfs will get similar timestamp
    set behavior as utimes.

    AV: get rid of clamping in ->setattr() instances; we don't need
    to bother with that there, with notify_change() doing normalization
    in all cases now (it already did for implicit case, since current_time()
    clamps).

    Suggested-by: Miklos Szeredi
    Fixes: 42e729b9ddbb ("utimes: Clamp the timestamps before update")
    Cc: stable@vger.kernel.org # v5.4
    Cc: Deepa Dinamani
    Cc: Jeff Layton
    Signed-off-by: Amir Goldstein
    Signed-off-by: Al Viro

    Amir Goldstein
     

15 Nov, 2019

1 commit


30 Aug, 2019

1 commit

  • POSIX is ambiguous on the behavior of timestamps for
    futimens, utimensat and utimes. Whether to return an
    error or silently clamp a timestamp beyond the range
    supported by the underlying filesystems is not clear.

    POSIX.1 section for futimens, utimensat and utimes says:
    (http://pubs.opengroup.org/onlinepubs/9699919799/functions/futimens.html)

    The file's relevant timestamp shall be set to the greatest
    value supported by the file system that is not greater
    than the specified time.

    If the tv_nsec field of a timespec structure has the special
    value UTIME_NOW, the file's relevant timestamp shall be set
    to the greatest value supported by the file system that is
    not greater than the current time.

    [EINVAL]
    A new file timestamp would be a value whose tv_sec
    component is not a value supported by the file system.

    The patch chooses to clamp the timestamps according to the
    filesystem timestamp ranges and does not return an error.
    This is in line with the behavior of utime syscall also
    since the POSIX page(http://pubs.opengroup.org/onlinepubs/009695399/functions/utime.html)
    for utime does not mention returning an error or clamping like above.

    Same for utimes http://pubs.opengroup.org/onlinepubs/009695399/functions/utimes.html

    Signed-off-by: Deepa Dinamani
    Acked-by: Jeff Layton

    Deepa Dinamani
     

07 Feb, 2019

1 commit

  • A lot of system calls that pass a time_t somewhere have an implementation
    using a COMPAT_SYSCALL_DEFINEx() on 64-bit architectures, and have
    been reworked so that this implementation can now be used on 32-bit
    architectures as well.

    The missing step is to redefine them using the regular SYSCALL_DEFINEx()
    to get them out of the compat namespace and make it possible to build them
    on 32-bit architectures.

    Any system call that ends in 'time' gets a '32' suffix on its name for
    that version, while the others get a '_time32' suffix, to distinguish
    them from the normal version, which takes a 64-bit time argument in the
    future.

    In this step, only 64-bit architectures are changed, doing this rename
    first lets us avoid touching the 32-bit architectures twice.

    Acked-by: Catalin Marinas
    Signed-off-by: Arnd Bergmann

    Arnd Bergmann
     

29 Aug, 2018

3 commits

  • After changing over to 64-bit time_t syscalls, many architectures will
    want compat_sys_utimensat() but not respective handlers for utime(),
    utimes() and futimesat(). This adds a new __ARCH_WANT_SYS_UTIME32 to
    complement __ARCH_WANT_SYS_UTIME. For now, all 64-bit architectures that
    support CONFIG_COMPAT set it, but future 64-bit architectures will not
    (tile would not have needed it either, but got removed).

    As older 32-bit architectures get converted to using CONFIG_64BIT_TIME,
    they will have to use __ARCH_WANT_SYS_UTIME32 instead of
    __ARCH_WANT_SYS_UTIME. Architectures using the generic syscall ABI don't
    need either of them as they never had a utime syscall.

    Since the compat_utimbuf structure is now required outside of
    CONFIG_COMPAT, I'm moving it into compat_time.h.

    Signed-off-by: Arnd Bergmann
    ---
    changed from last version:
    - renamed __ARCH_WANT_COMPAT_SYS_UTIME to __ARCH_WANT_SYS_UTIME32

    Arnd Bergmann
     
  • There are four generations of utimes() syscalls: utime(), utimes(),
    futimesat() and utimensat(), each one being a superset of the previous
    one. For y2038 support, we have to add another one, which is the same
    as the existing utimensat() but always passes 64-bit times_t based
    timespec values.

    There are currently 10 architectures that only use utimensat(), two
    that use utimes(), futimesat() and utimensat() but not utime(), and 11
    architectures that have all four, and those define __ARCH_WANT_SYS_UTIME
    in order to get a sys_utime implementation. Since all the new
    architectures only want utimensat(), moving all the legacy entry points
    into a common __ARCH_WANT_SYS_UTIME guard simplifies the logic. Only alpha
    and ia64 grow a tiny bit as they now also get an unused sys_utime(),
    but it didn't seem worth the extra complexity of adding yet another
    ifdef for those.

    Signed-off-by: Arnd Bergmann

    Arnd Bergmann
     
  • When 32-bit architectures get changed to support 64-bit time_t,
    utimensat() needs to use the new __kernel_timespec structure as its
    argument.

    The older utime(), utimes() and futimesat() system calls don't need a
    corresponding change as they are no longer used on C libraries that have
    64-bit time support.

    As we do for the other syscalls that have timespec arguments, we reuse
    the 'compat' syscall entry points to implement the traditional four
    interfaces, and only leave the new utimensat() as a native handler,
    so that the same code gets used on both 32-bit and 64-bit kernels
    on each syscall.

    Signed-off-by: Arnd Bergmann

    Arnd Bergmann
     

27 Aug, 2018

1 commit

  • Christoph Hellwig suggested a slightly different path for handling
    backwards compatibility with the 32-bit time_t based system calls:

    Rather than simply reusing the compat_sys_* entry points on 32-bit
    architectures unchanged, we get rid of those entry points and the
    compat_time types by renaming them to something that makes more sense
    on 32-bit architectures (which don't have a compat mode otherwise),
    and then share the entry points under the new name with the 64-bit
    architectures that use them for implementing the compatibility.

    The following types and interfaces are renamed here, and moved
    from linux/compat_time.h to linux/time32.h:

    old new
    --- ---
    compat_time_t old_time32_t
    struct compat_timeval struct old_timeval32
    struct compat_timespec struct old_timespec32
    struct compat_itimerspec struct old_itimerspec32
    ns_to_compat_timeval() ns_to_old_timeval32()
    get_compat_itimerspec64() get_old_itimerspec32()
    put_compat_itimerspec64() put_old_itimerspec32()
    compat_get_timespec64() get_old_timespec32()
    compat_put_timespec64() put_old_timespec32()

    As we already have aliases in place, this patch addresses only the
    instances that are relevant to the system call interface in particular,
    not those that occur in device drivers and other modules. Those
    will get handled separately, while providing the 64-bit version
    of the respective interfaces.

    I'm not renaming the timex, rusage and itimerval structures, as we are
    still debating what the new interface will look like, and whether we
    will need a replacement at all.

    This also doesn't change the names of the syscall entry points, which can
    be done more easily when we actually switch over the 32-bit architectures
    to use them, at that point we need to change COMPAT_SYSCALL_DEFINEx to
    SYSCALL_DEFINEx with a new name, e.g. with a _time32 suffix.

    Suggested-by: Christoph Hellwig
    Link: https://lore.kernel.org/lkml/20180705222110.GA5698@infradead.org/
    Signed-off-by: Arnd Bergmann

    Arnd Bergmann
     

03 Apr, 2018

2 commits


02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

04 Sep, 2017

1 commit

  • struct timespec is not y2038 safe on 32 bit machines.
    Replace timespec with y2038 safe struct timespec64.

    Note that the patch only changes the internals without
    modifying the syscall interfaces. This will be part
    of a separate series.

    Signed-off-by: Deepa Dinamani
    Reviewed-by: Arnd Bergmann
    Signed-off-by: Al Viro

    Deepa Dinamani
     

18 Apr, 2017

1 commit


25 Dec, 2016

1 commit


06 Dec, 2016

1 commit


08 Oct, 2016

1 commit


22 Sep, 2016

1 commit

  • inode_change_ok() will be resposible for clearing capabilities and IMA
    extended attributes and as such will need dentry. Give it as an argument
    to inode_change_ok() instead of an inode. Also rename inode_change_ok()
    to setattr_prepare() to better relect that it does also some
    modifications in addition to checks.

    Reviewed-by: Christoph Hellwig
    Signed-off-by: Jan Kara

    Jan Kara
     

16 Sep, 2016

1 commit

  • This fixes a bug where the permission was not properly checked in
    overlayfs. The testcase is ltp/utimensat01.

    It is also cleaner and safer to do the permission checking in the vfs
    helper instead of the caller.

    This patch introduces an additional ia_valid flag ATTR_TOUCH (since
    touch(1) is the most obvious user of utimes(NULL)) that is passed into
    notify_change whenever the conditions for this special permission checking
    mode are met.

    Reported-by: Aihua Zhang
    Signed-off-by: Miklos Szeredi
    Tested-by: Aihua Zhang
    Cc: # v3.18+

    Miklos Szeredi
     

07 Aug, 2016

1 commit

  • In most cases, EPERM is returned on immutable inode, and there're only a
    few places returning EACCES. I noticed this when running LTP on
    overlayfs, setxattr03 failed due to unexpected EACCES on immutable
    inode.

    So converting all EACCES to EPERM on immutable inode.

    Acked-by: Dave Chinner
    Signed-off-by: Eryu Guan
    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Eryu Guan
     

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
     

09 Nov, 2013

1 commit


21 Dec, 2012

1 commit


27 Sep, 2012

1 commit


30 May, 2012

1 commit


24 Mar, 2011

1 commit


14 Aug, 2010

1 commit

  • Mark arguments to certain system calls as being const where they should be but
    aren't. The list includes:

    (*) The filename arguments of various stat syscalls, execve(), various utimes
    syscalls and some mount syscalls.

    (*) The filename arguments of some syscall helpers relating to the above.

    (*) The buffer argument of various write syscalls.

    Signed-off-by: David Howells
    Acked-by: David S. Miller
    Signed-off-by: Linus Torvalds

    David Howells
     

14 Jan, 2009

2 commits


27 Jul, 2008

5 commits

  • * do not pass nameidata; struct path is all the callers want.
    * switch to new helpers:
    user_path_at(dfd, pathname, flags, &path)
    user_path(pathname, &path)
    user_lpath(pathname, &path)
    user_path_dir(pathname, &path) (fail if not a directory)
    The last 3 are trivial macro wrappers for the first one.
    * remove nameidata in callers.

    Signed-off-by: Al Viro

    Al Viro
     
  • Incidentally, the name that gives hundreds of false positives on grep
    is not a good idea...

    Signed-off-by: Al Viro

    Al Viro
     
  • Move the immutable and append-only checks from chmod, chown and utimes
    into notify_change(). Checks for immutable and append-only files are
    always performed by the VFS and not by the filesystem (see
    permission() and may_...() in namei.c), so these belong in
    notify_change(), and not in inode_change_ok().

    This should be completely equivalent.

    CC: Ulrich Drepper
    CC: Michael Kerrisk
    Signed-off-by: Miklos Szeredi
    Signed-off-by: Al Viro

    Miklos Szeredi
     
  • Untange the mess that is do_utimes(). Add kerneldoc comment to
    do_utimes().

    CC: Ulrich Drepper
    CC: Michael Kerrisk
    Signed-off-by: Miklos Szeredi
    Signed-off-by: Al Viro

    Miklos Szeredi
     
  • Add a new ia_valid flag: ATTR_TIMES_SET, to handle the
    UTIMES_OMIT/UTIMES_NOW and UTIMES_NOW/UTIMES_OMIT cases. In these
    cases neither ATTR_MTIME_SET nor ATTR_ATIME_SET is in the flags, yet
    the POSIX draft specifies that permission checking is performed the
    same way as if one or both of the times was explicitly set to a
    timestamp.

    See the path "vfs: utimensat(): fix error checking for
    {UTIME_NOW,UTIME_OMIT} case" by Michael Kerrisk for the patch
    introducing this behavior.

    This is a cleanup, as well as allowing filesystems (NFS/fuse/...) to
    perform their own permission checking instead of the default.

    CC: Ulrich Drepper
    CC: Michael Kerrisk
    Signed-off-by: Miklos Szeredi
    Signed-off-by: Al Viro

    Miklos Szeredi
     

23 Jun, 2008

3 commits

  • The POSIX.1 draft spec for futimens()/utimensat() says:

    Only a process with the effective user ID equal to the
    user ID of the file, *or with write access to the file*,
    or with appropriate privileges may use futimens() or
    utimensat() with a null pointer as the times argument
    or with both tv_nsec fields set to the special value
    UTIME_NOW.

    The important piece here is "with write access to the file", and
    this matters for futimens(), which deals with an argument that
    is a file descriptor referring to the file whose timestamps are
    being updated, The standard is saying that the "writability"
    check is based on the file permissions, not the access mode with
    which the file is opened. (This behavior is consistent with the
    semantics of FreeBSD's futimes().) However, Linux is currently
    doing the latter -- futimens(fd, times) is a library
    function implemented as

    utimensat(fd, NULL, times, 0)

    and within the utimensat() implementation we have the code:

    f = fget(dfd); // dfd is 'fd'
    ...
    if (f) {
    if (!(f->f_mode & FMODE_WRITE))
    goto mnt_drop_write_and_out;

    The check should instead be based on the file permissions.

    Thanks to Miklos for pointing out how to do this check.
    Miklos also pointed out a simplification that could be
    made to my first version of this patch, since the checks
    for the pathname and file descriptor cases can now be
    conflated.

    Acked-by: Miklos Szeredi
    Cc: Al Viro
    Cc: Ulrich Drepper
    Signed-off-by: Michael Kerrisk
    Signed-off-by: Andrew Morton
    Signed-off-by: Al Viro

    Michael Kerrisk
     
  • The POSIX.1 draft spec for utimensat() says:

    Only a process with the effective user ID equal to the
    user ID of the file or with appropriate privileges may use
    futimens() or utimensat() with a non-null times argument
    that does not have both tv_nsec fields set to UTIME_NOW
    and does not have both tv_nsec fields set to UTIME_OMIT.

    If this condition is violated, then the error EPERM should result.
    However, the current implementation does not generate EPERM if
    one tv_nsec field is UTIME_NOW while the other is UTIME_OMIT.
    It should give this error for that case.

    This patch:

    a) Repairs that problem.
    b) Removes the now unneeded nsec_special() helper function.
    c) Adds some comments to explain the checks that are being
    performed.

    Thanks to Miklos, who provided comments on the previous iteration
    of this patch. As a result, this version is a little simpler and
    and its logic is better structured.

    Miklos suggested an alternative idea, migrating the
    is_owner_or_cap() checks into fs/attr.c:inode_change_ok() via
    the use of an ATTR_OWNER_CHECK flag. Maybe we could do that
    later, but for now I've gone with this version, which is
    IMO simpler, and can be more easily read as being correct.

    Acked-by: Miklos Szeredi
    Cc: Al Viro
    Cc: Ulrich Drepper
    Signed-off-by: Michael Kerrisk
    Signed-off-by: Andrew Morton
    Signed-off-by: Al Viro

    Michael Kerrisk
     
  • The POSIX.1 draft spec for utimensat() says that if a times[n].tv_nsec
    field is UTIME_OMIT or UTIME_NOW, then the value in the corresponding
    tv_sec field is ignored. See the last sentence of this para, from
    the spec:

    If the tv_nsec field of a timespec structure has
    the special value UTIME_NOW, the file's relevant
    timestamp shall be set to the greatest value
    supported by the file system that is not greater than
    the current time. If the tv_nsec field has the
    special value UTIME_OMIT, the file's relevant
    timestamp shall not be changed. In either case,
    the tv_sec field shall be ignored.

    However the current Linux implementation requires the tv_sec value to be
    zero (or the EINVAL error results). This requirement should be removed.

    Acked-by: Miklos Szeredi
    Cc: Al Viro
    Cc: Ulrich Drepper
    Signed-off-by: Michael Kerrisk
    Signed-off-by: Andrew Morton
    Signed-off-by: Al Viro

    Michael Kerrisk