1. 15 Apr, 2011 1 commit
  2. 31 Mar, 2011 1 commit
  3. 24 Mar, 2011 1 commit
  4. 23 Mar, 2011 3 commits
  5. 18 Mar, 2011 2 commits
  6. 16 Mar, 2011 1 commit
  7. 15 Mar, 2011 10 commits
    • Al Viro's avatar
      tidy the trailing symlinks traversal up · 574197e0
      Al Viro authored
      * pull the handling of current->total_link_count into
      * put the common "do ->put_link() if needed and path_put() the link"
        stuff into a helper (put_link(nd, link, cookie))
      * rename __do_follow_link() to follow_link(), while we are at it
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      Turn resolution of trailing symlinks iterative everywhere · b356379a
      Al Viro authored
      The last remaining place (resolution of nested symlink) converted
      to the loop of the same kind we have in path_lookupat() and
      Note that we still *do* have a recursion in pathname resolution;
      can't avoid it, really.  However, it's strictly for nested symlinks
      now - i.e. ones in the middle of a pathname.
      link_path_walk() has lost the tail now - it always walks everything
      except the last component.
      do_follow_link() renamed to nested_symlink() and moved down.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      simplify link_path_walk() tail · ce052544
      Al Viro authored
      Now that link_path_walk() is called without LOOKUP_PARENT
      only from do_follow_link(), we can simplify the checks in
      last component handling.  First of all, checking if we'd
      arrived to a directory is not needed - the caller will check
      it anyway.  And LOOKUP_FOLLOW is guaranteed to be there,
      since we only get to that place with nd->depth > 0.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      Make trailing symlink resolution in path_lookupat() iterative · bd92d7fe
      Al Viro authored
      Now the only caller of link_path_walk() that does *not* pass
      LOOKUP_PARENT is do_follow_link()
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      update nd->inode in __do_follow_link() instead of after do_follow_link() · b21041d0
      Al Viro authored
      ... and note that we only need to do it for LAST_BIND symlinks
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      pull handling of one pathname component into a helper · ce57dfc1
      Al Viro authored
      new helper: walk_component().  Handles everything except symlinks;
      returns negative on error, 0 on success and 1 on symlinks we decided
      to follow.  Drops out of RCU mode on such symlinks.
      link_path_walk() and do_last() switched to using that.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Aneesh Kumar K.V's avatar
      fs: allow AT_EMPTY_PATH in linkat(), limit that to CAP_DAC_READ_SEARCH · 11a7b371
      Aneesh Kumar K.V authored
      We don't want to allow creation of private hardlinks by different application
      using the fd passed to them via SCM_RIGHTS. So limit the null relative name
      usage in linkat syscall to CAP_DAC_READ_SEARCH
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    • Al Viro's avatar
      Allow O_PATH for symlinks · bcda7652
      Al Viro authored
      At that point we can't do almost nothing with them.  They can be opened
      with O_PATH, we can manipulate such descriptors with dup(), etc. and
      we can see them in /proc/*/{fd,fdinfo}/*.
      We can't (and won't be able to) follow /proc/*/fd/* symlinks for those;
      there's simply not enough information for pathname resolution to go on
      from such point - to resolve a symlink we need to know which directory
      does it live in.
      We will be able to do useful things with them after the next commit, though -
      readlinkat() and fchownat() will be possible to use with dfd being an
      O_PATH-opened symlink and empty relative pathname.  Combined with
      open_by_handle() it'll give us a way to do realink-by-handle and
      lchown-by-handle without messing with more redundant syscalls.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      New kind of open files - "location only". · 1abf0c71
      Al Viro authored
      New flag for open(2) - O_PATH.  Semantics:
      	* pathname is resolved, but the file itself is _NOT_ opened
      as far as filesystem is concerned.
      	* almost all operations on the resulting descriptors shall
      fail with -EBADF.  Exceptions are:
      	1) operations on descriptors themselves (i.e.
      		close(), dup(), dup2(), dup3(), fcntl(fd, F_DUPFD),
      		fcntl(fd, F_DUPFD_CLOEXEC, ...), fcntl(fd, F_GETFD),
      		fcntl(fd, F_SETFD, ...))
      	2) fcntl(fd, F_GETFL), for a common non-destructive way to
      		check if descriptor is open
      	3) "dfd" arguments of ...at(2) syscalls, i.e. the starting
      		points of pathname resolution
      	* closing such descriptor does *NOT* affect dnotify or
      posix locks.
      	* permissions are checked as usual along the way to file;
      no permission checks are applied to the file itself.  Of course,
      giving such thing to syscall will result in permission checks (at
      the moment it means checking that starting point of ....at() is
      a directory and caller has exec permissions on it).
      fget() and fget_light() return NULL on such descriptors; use of
      fget_raw() and fget_raw_light() is needed to get them.  That protects
      existing code from dealing with those things.
      There are two things still missing (they come in the next commits):
      one is handling of symlinks (right now we refuse to open them that
      way; see the next commit for semantics related to those) and another
      is descriptor passing via SCM_RIGHTS datagrams.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Aneesh Kumar K.V's avatar
      fs: Don't allow to create hardlink for deleted file · aae8a97d
      Aneesh Kumar K.V authored
      Add inode->i_nlink == 0 check in VFS. Some of the file systems
      do this internally. A followup patch will remove those instance.
      This is needed to ensure that with link by handle we don't allow
      to create hardlink of an unlinked file. The check also prevent a race
      between unlink and link
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  8. 14 Mar, 2011 21 commits