1. 08 Jul, 2017 1 commit
    • Al Viro's avatar
      dentry name snapshots · 49d31c2f
      Al Viro authored
      take_dentry_name_snapshot() takes a safe snapshot of dentry name;
      if the name is a short one, it gets copied into caller-supplied
      structure, otherwise an extra reference to external name is grabbed
      (those are never modified).  In either case the pointer to stable
      string is stored into the same structure.
      dentry must be held by the caller of take_dentry_name_snapshot(),
      but may be freely dropped afterwards - the snapshot will stay
      until destroyed by release_dentry_name_snapshot().
      Intended use:
      	struct name_snapshot s;
      	take_dentry_name_snapshot(&s, dentry);
      	access s.name
      Replaces fsnotify_oldname_...(), gets used in fsnotify to obtain the name
      to pass down with event.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  2. 06 Jul, 2017 1 commit
  3. 30 Jun, 2017 1 commit
  4. 16 May, 2017 1 commit
  5. 09 May, 2017 1 commit
  6. 21 Apr, 2017 2 commits
  7. 15 Apr, 2017 1 commit
  8. 29 Mar, 2017 1 commit
  9. 07 Feb, 2017 1 commit
  10. 01 Feb, 2017 2 commits
    • Eric W. Biederman's avatar
      fs: Better permission checking for submounts · 93faccbb
      Eric W. Biederman authored
      To support unprivileged users mounting filesystems two permission
      checks have to be performed: a test to see if the user allowed to
      create a mount in the mount namespace, and a test to see if
      the user is allowed to access the specified filesystem.
      The automount case is special in that mounting the original filesystem
      grants permission to mount the sub-filesystems, to any user who
      happens to stumble across the their mountpoint and satisfies the
      ordinary filesystem permission checks.
      Attempting to handle the automount case by using override_creds
      almost works.  It preserves the idea that permission to mount
      the original filesystem is permission to mount the sub-filesystem.
      Unfortunately using override_creds messes up the filesystems
      ordinary permission checks.
      Solve this by being explicit that a mount is a submount by introducing
      vfs_submount, and using it where appropriate.
      vfs_submount uses a new mount internal mount flags MS_SUBMOUNT, to let
      sget and friends know that a mount is a submount so they can take appropriate
      sget and sget_userns are modified to not perform any permission checks
      on submounts.
      follow_automount is modified to stop using override_creds as that
      has proven problemantic.
      do_mount is modified to always remove the new MS_SUBMOUNT flag so
      that we know userspace will never by able to specify it.
      autofs4 is modified to stop using current_real_cred that was put in
      there to handle the previous version of submount permission checking.
      cifs is modified to pass the mountpoint all of the way down to vfs_submount.
      debugfs is modified to pass the mountpoint all of the way down to
      trace_automount by adding a new parameter.  To make this change easier
      a new typedef debugfs_automount_t is introduced to capture the type of
      the debugfs automount function.
      Cc: stable@vger.kernel.org
      Fixes: 069d5ac9 ("autofs:  Fix automounts by using current_real_cred()->uid")
      Fixes: aeaa4a79 ("fs: Call d_automount with the filesystems creds")
      Reviewed-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Reviewed-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
    • Seth Forshee's avatar
      vfs: open() with O_CREAT should not create inodes with unknown ids · 1328c727
      Seth Forshee authored
      may_create() rejects creation of inodes with ids which lack a
      mapping into s_user_ns. However for O_CREAT may_o_create() is
      is used instead. Add a similar check there.
      Fixes: 036d5236 ("vfs: Don't create inodes with a uid or gid unknown to the vfs")
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
  11. 10 Jan, 2017 2 commits
  12. 09 Jan, 2017 2 commits
  13. 24 Dec, 2016 1 commit
  14. 16 Dec, 2016 1 commit
  15. 09 Dec, 2016 4 commits
  16. 06 Dec, 2016 7 commits
  17. 03 Dec, 2016 1 commit
  18. 14 Oct, 2016 1 commit
    • Miklos Szeredi's avatar
      vfs: add vfs_get_link() helper · d60874cd
      Miklos Szeredi authored
      This helper is for filesystems that want to read the symlink and are better
      off with the get_link() interface (returning a char *) rather than the
      readlink() interface (copy into a userspace buffer).
      Also call the LSM hook for readlink (not get_link) since this is for
      symlink reading not following.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
  19. 27 Sep, 2016 2 commits
  20. 16 Sep, 2016 1 commit
    • Miklos Szeredi's avatar
      vfs: update ovl inode before relatime check · 598e3c8f
      Miklos Szeredi authored
      On overlayfs relatime_need_update() needs inode times to be correct on
      overlay inode.  But i_mtime and i_ctime are updated by filesystem code on
      underlying inode only, so they will be out-of-date on the overlay inode.
      This patch copies the times from the underlying inode if needed.  This
      can't be done if called from RCU lookup (link following) but link m/ctime
      are not updated by fs, so this is all right.
      This patch doesn't change functionality for anything but overlayfs.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
  21. 07 Aug, 2016 1 commit
  22. 29 Jul, 2016 1 commit
    • Linus Torvalds's avatar
      Revert "vfs: add lookup_hash() helper" · 20d00ee8
      Linus Torvalds authored
      This reverts commit 3c9fe8cd.
      As Miklos points out in commit c1b2cc1a, the "lookup_hash()" helper
      is now unused, and in fact, with the hash salting changes, since the
      hash of a dentry name now depends on the directory dentry it is in, the
      helper function isn't even really likely to be useful.
      So rather than keep it around in case somebody else might end up finding
      a use for it, let's just remove the helper and not trick people into
      thinking it might be a useful thing.
      For example, I had obviously completely missed how the helper didn't
      follow the normal dentry hashing patterns, and how the hash salting
      patch broke overlayfs.  Things would quietly build and look sane, but
      not work.
      Suggested-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  23. 24 Jul, 2016 1 commit
  24. 23 Jul, 2016 1 commit
    • Eric W. Biederman's avatar
      fs: Call d_automount with the filesystems creds · aeaa4a79
      Eric W. Biederman authored
      Seth Forshee reported a mount regression in nfs autmounts
      with "fs: Add user namespace member to struct super_block".
      It turns out that the assumption that current->cred is something
      reasonable during mount while necessary to improve support of
      unprivileged mounts is wrong in the automount path.
      To fix the existing filesystems override current->cred with the
      init_cred before calling d_automount and restore current->cred after
      d_automount completes.
      To support unprivileged mounts would require a more nuanced cred
      selection, so fail on unprivileged mounts for the time being.  As none
      of the filesystems that currently set FS_USERNS_MOUNT implement
      d_automount this check is only good for preventing future problems.
      Fixes: 6e4eab57 ("fs: Add user namespace member to struct super_block")
      Tested-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
  25. 05 Jul, 2016 2 commits
    • Eric W. Biederman's avatar
      vfs: Don't create inodes with a uid or gid unknown to the vfs · 036d5236
      Eric W. Biederman authored
      It is expected that filesystems can not represent uids and gids from
      outside of their user namespace.  Keep things simple by not even
      trying to create filesystem nodes with non-sense uids and gids.
      Acked-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
    • Eric W. Biederman's avatar
      vfs: Don't modify inodes with a uid or gid unknown to the vfs · 0bd23d09
      Eric W. Biederman authored
      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: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>