Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 8月, 2013 6 次提交
  3. 09 8月, 2013 1 次提交
  5. 08 8月, 2013 20 次提交
  7. 07 8月, 2013 9 次提交
  9. 05 8月, 2013 4 次提交
    • Z
      vfs: add missing check for __O_TMPFILE in fcntl_init() · 3d62c45b
      由 Zheng Liu 提交于 
      As comment in include/uapi/asm-generic/fcntl.h described, when
introducing new O_* bits, we need to check its uniqueness in
fcntl_init().  But __O_TMPFILE bit is missing.  So fix it.
Signed-off-by: NZheng Liu <wenqing.lz@taobao.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      3d62c45b
    • A
      fs: Allow unprivileged linkat(..., AT_EMPTY_PATH) aka flink · bb2314b4
      由 Andy Lutomirski 提交于 
      Every now and then someone proposes a new flink syscall, and this spawns
a long discussion of whether it would be a security problem.  I think
that this is missing the point: flink is *already* allowed without
privilege as long as /proc is mounted -- it's called AT_SYMLINK_FOLLOW.

Now that O_TMPFILE is here, the ability to create a file with O_TMPFILE,
write it, and link it in is very convenient.  The only problem is that
it requires that /proc be mounted so that you can do:

linkat(AT_FDCWD, "/proc/self/fd/<tmpfd>", dfd, path, AT_SYMLINK_NOFOLLOW)

This sucks -- it's much nicer to do:

linkat(tmpfd, "", dfd, path, AT_EMPTY_PATH)

Let's allow it.

If this turns out to be excessively scary, it we could instead require
that the inode in question be I_LINKABLE, but this seems pointless given
the /proc situation
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bb2314b4
    • A
      fs: Fix file mode for O_TMPFILE · e305f48b
      由 Andy Lutomirski 提交于 
      O_TMPFILE, like O_CREAT, should respect the requested mode and should
create regular files.

This fixes two bugs: O_TMPFILE required privilege (because the mode
ended up as 000) and it produced bogus inodes with no type.
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      e305f48b
    • A
      reiserfs: fix deadlock in umount · 672fe15d
      由 Al Viro 提交于 
      Since remove_proc_entry() started to wait for IO in progress (i.e.
since 2007 or so), the locking in fs/reiserfs/proc.c became wrong;
if procfs read happens between the moment when umount() locks the
victim superblock and removal of /proc/fs/reiserfs/<device>/*,
we'll get a deadlock - read will wait for s_umount (in sget(),
called by r_start()), while umount will wait in remove_proc_entry()
for that read to finish, holding s_umount all along.

Fortunately, the same change allows a much simpler race avoidance -
all we need to do is remove the procfs entries in the very beginning
of reiserfs ->kill_sb(); that'll guarantee that pointer to superblock
will remain valid for the duration for procfs IO, so we don't need
sget() to keep the sucker alive.  As the matter of fact, we can
get rid of the home-grown iterator completely, and use single_open()
instead.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      672fe15d