1. 08 7月, 2016 1 次提交
  2. 20 6月, 2016 1 次提交
  3. 09 5月, 2016 1 次提交
  4. 05 5月, 2016 1 次提交
    • A
      ecryptfs: fix handling of directory opening · 6a480a78
      Al Viro 提交于
      First of all, trying to open them r/w is idiocy; it's guaranteed to fail.
      Moreover, assigning ->f_pos and assuming that everything will work is
      blatantly broken - try that with e.g. tmpfs as underlying layer and watch
      the fireworks.  There may be a non-trivial amount of state associated with
      current IO position, well beyond the numeric offset.  Using the single
      struct file associated with underlying inode is really not a good idea;
      we ought to open one for each ecryptfs directory struct file.
      
      Additionally, file_operations both for directories and non-directories are
      full of pointless methods; non-directories should *not* have ->iterate(),
      directories should not have ->flush(), ->fasync() and ->splice_read().
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6a480a78
  5. 10 7月, 2015 1 次提交
  6. 16 4月, 2015 1 次提交
  7. 12 4月, 2015 1 次提交
  8. 26 3月, 2015 1 次提交
  9. 14 3月, 2015 1 次提交
  10. 03 3月, 2015 1 次提交
    • T
      eCryptfs: don't pass fs-specific ioctl commands through · 6d65261a
      Tyler Hicks 提交于
      eCryptfs can't be aware of what to expect when after passing an
      arbitrary ioctl command through to the lower filesystem. The ioctl
      command may trigger an action in the lower filesystem that is
      incompatible with eCryptfs.
      
      One specific example is when one attempts to use the Btrfs clone
      ioctl command when the source file is in the Btrfs filesystem that
      eCryptfs is mounted on top of and the destination fd is from a new file
      created in the eCryptfs mount. The ioctl syscall incorrectly returns
      success because the command is passed down to Btrfs which thinks that it
      was able to do the clone operation. However, the result is an empty
      eCryptfs file.
      
      This patch allows the trim, {g,s}etflags, and {g,s}etversion ioctl
      commands through and then copies up the inode metadata from the lower
      inode to the eCryptfs inode to catch any changes made to the lower
      inode's metadata. Those five ioctl commands are mostly common across all
      filesystems but the whitelist may need to be further pruned in the
      future.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=93691
      https://launchpad.net/bugs/1305335Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      Cc: Rocko <rockorequin@hotmail.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: stable@vger.kernel.org # v2.6.36+: c43f7b8f eCryptfs: Handle ioctl calls with unlocked and compat functions
      6d65261a
  11. 23 2月, 2015 1 次提交
    • D
      VFS: (Scripted) Convert S_ISLNK/DIR/REG(dentry->d_inode) to d_is_*(dentry) · e36cb0b8
      David Howells 提交于
      Convert the following where appropriate:
      
       (1) S_ISLNK(dentry->d_inode) to d_is_symlink(dentry).
      
       (2) S_ISREG(dentry->d_inode) to d_is_reg(dentry).
      
       (3) S_ISDIR(dentry->d_inode) to d_is_dir(dentry).  This is actually more
           complicated than it appears as some calls should be converted to
           d_can_lookup() instead.  The difference is whether the directory in
           question is a real dir with a ->lookup op or whether it's a fake dir with
           a ->d_automount op.
      
      In some circumstances, we can subsume checks for dentry->d_inode not being
      NULL into this, provided we the code isn't in a filesystem that expects
      d_inode to be NULL if the dirent really *is* negative (ie. if we're going to
      use d_inode() rather than d_backing_inode() to get the inode pointer).
      
      Note that the dentry type field may be set to something other than
      DCACHE_MISS_TYPE when d_inode is NULL in the case of unionmount, where the VFS
      manages the fall-through from a negative dentry to a lower layer.  In such a
      case, the dentry type of the negative union dentry is set to the same as the
      type of the lower dentry.
      
      However, if you know d_inode is not NULL at the call site, then you can use
      the d_is_xxx() functions even in a filesystem.
      
      There is one further complication: a 0,0 chardev dentry may be labelled
      DCACHE_WHITEOUT_TYPE rather than DCACHE_SPECIAL_TYPE.  Strictly, this was
      intended for special directory entry types that don't have attached inodes.
      
      The following perl+coccinelle script was used:
      
      use strict;
      
      my @callers;
      open($fd, 'git grep -l \'S_IS[A-Z].*->d_inode\' |') ||
          die "Can't grep for S_ISDIR and co. callers";
      @callers = <$fd>;
      close($fd);
      unless (@callers) {
          print "No matches\n";
          exit(0);
      }
      
      my @cocci = (
          '@@',
          'expression E;',
          '@@',
          '',
          '- S_ISLNK(E->d_inode->i_mode)',
          '+ d_is_symlink(E)',
          '',
          '@@',
          'expression E;',
          '@@',
          '',
          '- S_ISDIR(E->d_inode->i_mode)',
          '+ d_is_dir(E)',
          '',
          '@@',
          'expression E;',
          '@@',
          '',
          '- S_ISREG(E->d_inode->i_mode)',
          '+ d_is_reg(E)' );
      
      my $coccifile = "tmp.sp.cocci";
      open($fd, ">$coccifile") || die $coccifile;
      print($fd "$_\n") || die $coccifile foreach (@cocci);
      close($fd);
      
      foreach my $file (@callers) {
          chomp $file;
          print "Processing ", $file, "\n";
          system("spatch", "--sp-file", $coccifile, $file, "--in-place", "--no-show-diff") == 0 ||
      	die "spatch failed";
      }
      
      [AV: overlayfs parts skipped]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      e36cb0b8
  12. 01 11月, 2014 1 次提交
  13. 23 10月, 2014 1 次提交
    • T
      eCryptfs: Force RO mount when encrypted view is enabled · 332b122d
      Tyler Hicks 提交于
      The ecryptfs_encrypted_view mount option greatly changes the
      functionality of an eCryptfs mount. Instead of encrypting and decrypting
      lower files, it provides a unified view of the encrypted files in the
      lower filesystem. The presence of the ecryptfs_encrypted_view mount
      option is intended to force a read-only mount and modifying files is not
      supported when the feature is in use. See the following commit for more
      information:
      
        e77a56dd [PATCH] eCryptfs: Encrypted passthrough
      
      This patch forces the mount to be read-only when the
      ecryptfs_encrypted_view mount option is specified by setting the
      MS_RDONLY flag on the superblock. Additionally, this patch removes some
      broken logic in ecryptfs_open() that attempted to prevent modifications
      of files when the encrypted view feature was in use. The check in
      ecryptfs_open() was not sufficient to prevent file modifications using
      system calls that do not operate on a file descriptor.
      Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      Reported-by: NPriya Bansal <p.bansal@samsung.com>
      Cc: stable@vger.kernel.org # v2.6.21+: e77a56dd [PATCH] eCryptfs: Encrypted passthrough
      332b122d
  14. 09 10月, 2014 1 次提交
  15. 07 5月, 2014 2 次提交
  16. 18 12月, 2013 1 次提交
  17. 15 11月, 2013 1 次提交
    • T
      eCryptfs: file->private_data is always valid · 2000f5be
      Tyler Hicks 提交于
      When accessing the lower_file pointer located in private_data of
      eCryptfs files, there is no need to check to see if the private_data
      pointer has been initialized to a non-NULL value. The file->private_data
      and file->private_data->lower_file pointers are always initialized to
      non-NULL values in ecryptfs_open().
      
      This change quiets a Smatch warning:
      
        CHECK   /var/scm/kernel/linux/fs/ecryptfs/file.c
      fs/ecryptfs/file.c:321 ecryptfs_unlocked_ioctl() error: potential NULL dereference 'lower_file'.
      fs/ecryptfs/file.c:335 ecryptfs_compat_ioctl() error: potential NULL dereference 'lower_file'.
      Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: NGeyslan G. Bem <geyslan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      2000f5be
  18. 10 11月, 2013 1 次提交
  19. 25 10月, 2013 1 次提交
  20. 10 7月, 2013 1 次提交
  21. 29 6月, 2013 3 次提交
  22. 05 6月, 2013 1 次提交
  23. 25 5月, 2013 1 次提交
  24. 08 5月, 2013 1 次提交
  25. 23 2月, 2013 1 次提交
  26. 18 1月, 2013 1 次提交
  27. 15 9月, 2012 1 次提交
    • T
      eCryptfs: Call lower ->flush() from ecryptfs_flush() · 64e6651d
      Tyler Hicks 提交于
      Since eCryptfs only calls fput() on the lower file in
      ecryptfs_release(), eCryptfs should call the lower filesystem's
      ->flush() from ecryptfs_flush().
      
      If the lower filesystem implements ->flush(), then eCryptfs should try
      to flush out any dirty pages prior to calling the lower ->flush(). If
      the lower filesystem does not implement ->flush(), then eCryptfs has no
      need to do anything in ecryptfs_flush() since dirty pages are now
      written out to the lower filesystem in ecryptfs_release().
      Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      64e6651d
  28. 14 7月, 2012 1 次提交
    • T
      eCryptfs: Revert to a writethrough cache model · 821f7494
      Tyler Hicks 提交于
      A change was made about a year ago to get eCryptfs to better utilize its
      page cache during writes. The idea was to do the page encryption
      operations during page writeback, rather than doing them when initially
      writing into the page cache, to reduce the number of page encryption
      operations during sequential writes. This meant that the encrypted page
      would only be written to the lower filesystem during page writeback,
      which was a change from how eCryptfs had previously wrote to the lower
      filesystem in ecryptfs_write_end().
      
      The change caused a few eCryptfs-internal bugs that were shook out.
      Unfortunately, more grave side effects have been identified that will
      force changes outside of eCryptfs. Because the lower filesystem isn't
      consulted until page writeback, eCryptfs has no way to pass lower write
      errors (ENOSPC, mainly) back to userspace. Additionaly, it was reported
      that quotas could be bypassed because of the way eCryptfs may sometimes
      open the lower filesystem using a privileged kthread.
      
      It would be nice to resolve the latest issues, but it is best if the
      eCryptfs commits be reverted to the old behavior in the meantime.
      
      This reverts:
      32001d6f "eCryptfs: Flush file in vma close"
      5be79de2 "eCryptfs: Flush dirty pages in setattr"
      57db4e8d "ecryptfs: modify write path to encrypt page in writepage"
      Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      Tested-by: NColin King <colin.king@canonical.com>
      Cc: Colin King <colin.king@canonical.com>
      Cc: Thieu Le <thieule@google.com>
      821f7494
  29. 09 7月, 2012 1 次提交
    • T
      eCryptfs: Initialize empty lower files when opening them · e3ccaa97
      Tyler Hicks 提交于
      Historically, eCryptfs has only initialized lower files in the
      ecryptfs_create() path. Lower file initialization is the act of writing
      the cryptographic metadata from the inode's crypt_stat to the header of
      the file. The ecryptfs_open() path already expects that metadata to be
      in the header of the file.
      
      A number of users have reported empty lower files in beneath their
      eCryptfs mounts. Most of the causes for those empty files being left
      around have been addressed, but the presence of empty files causes
      problems due to the lack of proper cryptographic metadata.
      
      To transparently solve this problem, this patch initializes empty lower
      files in the ecryptfs_open() error path. If the metadata is unreadable
      due to the lower inode size being 0, plaintext passthrough support is
      not in use, and the metadata is stored in the header of the file (as
      opposed to the user.ecryptfs extended attribute), the lower file will be
      initialized.
      
      The number of nested conditionals in ecryptfs_open() was getting out of
      hand, so a helper function was created. To avoid the same nested
      conditional problem, the conditional logic was reversed inside of the
      helper function.
      
      https://launchpad.net/bugs/911507Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      Cc: John Johansen <john.johansen@canonical.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      e3ccaa97
  30. 21 3月, 2012 1 次提交
  31. 24 11月, 2011 1 次提交
  32. 21 7月, 2011 1 次提交
    • J
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      Josef Bacik 提交于
      Btrfs needs to be able to control how filemap_write_and_wait_range() is called
      in fsync to make it less of a painful operation, so push down taking i_mutex and
      the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
      file systems can drop taking the i_mutex altogether it seems, like ext3 and
      ocfs2.  For correctness sake I just pushed everything down in all cases to make
      sure that we keep the current behavior the same for everybody, and then each
      individual fs maintainer can make up their mind about what to do from there.
      Thanks,
      Acked-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      02c24a82
  33. 30 5月, 2011 1 次提交
  34. 26 4月, 2011 2 次提交
    • T
      eCryptfs: Handle failed metadata read in lookup · 3aeb86ea
      Tyler Hicks 提交于
      When failing to read the lower file's crypto metadata during a lookup,
      eCryptfs must continue on without throwing an error. For example, there
      may be a plaintext file in the lower mount point that the user wants to
      delete through the eCryptfs mount.
      
      If an error is encountered while reading the metadata in lookup(), the
      eCryptfs inode's size could be incorrect. We must be sure to reread the
      plaintext inode size from the metadata when performing an open() or
      setattr(). The metadata is already being read in those paths, so this
      adds minimal performance overhead.
      
      This patch introduces a flag which will track whether or not the
      plaintext inode size has been read so that an incorrect i_size can be
      fixed in the open() or setattr() paths.
      
      https://bugs.launchpad.net/bugs/509180
      
      Cc: <stable@kernel.org>
      Signed-off-by: NTyler Hicks <tyhicks@linux.vnet.ibm.com>
      3aeb86ea
    • T
      eCryptfs: Add reference counting to lower files · 332ab16f
      Tyler Hicks 提交于
      For any given lower inode, eCryptfs keeps only one lower file open and
      multiplexes all eCryptfs file operations through that lower file. The
      lower file was considered "persistent" and stayed open from the first
      lookup through the lifetime of the inode.
      
      This patch keeps the notion of a single, per-inode lower file, but adds
      reference counting around the lower file so that it is closed when not
      currently in use. If the reference count is at 0 when an operation (such
      as open, create, etc.) needs to use the lower file, a new lower file is
      opened. Since the file is no longer persistent, all references to the
      term persistent file are changed to lower file.
      
      Locking is added around the sections of code that opens the lower file
      and assign the pointer in the inode info, as well as the code the fputs
      the lower file when all eCryptfs users are done with it.
      
      This patch is needed to fix issues, when mounted on top of the NFSv3
      client, where the lower file is left silly renamed until the eCryptfs
      inode is destroyed.
      Signed-off-by: NTyler Hicks <tyhicks@linux.vnet.ibm.com>
      332ab16f
  35. 28 3月, 2011 1 次提交
  36. 22 2月, 2011 1 次提交