Skip to content

GitLab

Switch branch/tag
  1. 17 Jul, 2007 1 commit
    • Satyam Sharma's avatar
      Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check · 3bd858ab
      Satyam Sharma authored 
      
Introduce is_owner_or_cap() macro in fs.h, and convert over relevant
users to it. This is done because we want to avoid bugs in the future
where we check for only effective fsuid of the current task against a
file's owning uid, without simultaneously checking for CAP_FOWNER as
well, thus violating its semantics.
[ XFS uses special macros and structures, and in general looked ...
untouchable, so we leave it alone -- but it has been looked over. ]

The (current->fsuid != inode->i_uid) check in generic_permission() and
exec_permission_lite() is left alone, because those operations are
covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Similarly operations
falling under the purview of CAP_CHOWN and CAP_LEASE are also left alone.
Signed-off-by: default avatarSatyam Sharma <ssatyam@cse.iitk.ac.in>
Cc: Al Viro <viro@ftp.linux.org.uk>
Acked-by: default avatarSerge E. Hallyn <serge@hallyn.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3bd858ab
  3. 11 May, 2007 1 commit
  5. 09 May, 2007 2 commits
  7. 08 May, 2007 2 commits
  9. 07 May, 2007 1 commit
  11. 27 Apr, 2007 1 commit
  13. 16 Feb, 2007 1 commit
  15. 12 Feb, 2007 1 commit
  17. 08 Dec, 2006 2 commits
  19. 07 Dec, 2006 2 commits
  21. 01 Oct, 2006 2 commits
  23. 29 Sep, 2006 1 commit
  25. 27 Sep, 2006 1 commit
    • Ian Kent's avatar
      [PATCH] autofs4 needs to force fail return revalidate · bcdc5e01
      Ian Kent authored 
      
For a long time now I have had a problem with not being able to return a
lookup failure on an existsing directory.  In autofs this corresponds to a
mount failure on a autofs managed mount entry that is browsable (and so the
mount point directory exists).

While this problem has been present for a long time I've avoided resolving
it because it was not very visible.  But now that autofs v5 has "mount and
expire on demand" of nested multiple mounts, such as is found when mounting
an export list from a server, solving the problem cannot be avoided any
longer.

I've tried very hard to find a way to do this entirely within the autofs4
module but have not been able to find a satisfactory way to achieve it.

So, I need to propose a change to the VFS.
Signed-off-by: default avatarIan Kent <raven@themaw.net>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      bcdc5e01
  27. 24 Sep, 2006 1 commit
  29. 24 Aug, 2006 2 commits
    • Trond Myklebust's avatar
      VFS: Fix access("file", X_OK) in the presence of ACLs · a343bb77
      Trond Myklebust authored 
      
Currently, the access() call will return incorrect information on NFS if
there exists an ACL that grants execute access to the user on a regular
file. The reason the information is incorrect is that the VFS overrides
this execute access in open_exec() by checking (inode->i_mode & 0111).

This patch propagates the VFS execute bit check back into the generic
permission() call.
Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
(cherry picked from 64cbae98848c4c99851cb0a405f0b4982cd76c1e commit)
      a343bb77
    • ASANO Masahiro's avatar
      VFS: add lookup hint for network file systems · a634904a
      ASANO Masahiro authored 
      
I'm trying to speeding up mkdir(2) for network file systems.  A typical
mkdir(2) calls two inode_operations: lookup and mkdir.  The lookup
operation would fail with ENOENT in common case.  I think it is unnecessary
because the subsequent mkdir operation can check it.  In case of creat(2),
lookup operation is called with the LOOKUP_CREATE flag, so individual
filesystem can omit real lookup.  e.g.  nfs_lookup().

Here is a sample patch which uses LOOKUP_CREATE and O_EXCL on mkdir,
symlink and mknod.  This uses the gadget for creat(2).

And here is the result of a benchmark on NFSv3.
  mkdir(2) 10,000 times:
    original  50.5 sec
    patched   29.0 sec
Signed-off-by: default avatarASANO Masahiro <masano@tnes.nec.co.jp>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
(cherry picked from fab7bf44449b29f9d5572a5dd8adcf7c91d5bf0f commit)
      a634904a
  31. 03 Aug, 2006 3 commits
  33. 15 Jul, 2006 1 commit
    • Kirill Korotaev's avatar
      [PATCH] struct file leakage · de459215
      Kirill Korotaev authored 
      
2.6.16 leaks like hell. While testing, I found massive leakage
(reproduced in openvz) in:

*filp
*size-4096

And 1 object leaks in
*size-32
*size-64
*size-128

It is the fix for the first one.  filp leaks in the bowels of namei.c.

Seems, size-4096 is file table leaking in expand_fdtables.

I have no idea what are the rest and why they show only accompanying
another leaks.  Some debugging structs?

[akpm@osdl.org, Trond: remove the IS_ERR() check]
Signed-off-by: default avatarAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Kirill Korotaev <dev@openvz.org>
Cc: <stable@kernel.org>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      de459215
  35. 03 Jul, 2006 1 commit
  37. 25 Jun, 2006 1 commit
    • Ulrich Drepper's avatar
      [PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat · 45c9b11a
      Ulrich Drepper authored 
      
When the linkat() syscall was added the flag parameter was added in the
last minute but it wasn't used so far.  The following patch should change
that.  My tests show that this is all that's needed.

If OLDNAME is a symlink setting the flag causes linkat to follow the
symlink and create a hardlink with the target.  This is actually the
behavior POSIX demands for link() as well but Linux wisely does not do
this.  With this flag (which will most likely be in the next POSIX
revision) the programmer can choose the behavior, defaulting to the safe
variant.  As a side effect it is now possible to implement a
POSIX-compliant link(2) function for those who are interested.

  touch file
  ln -s file symlink

  linkat(fd, "symlink", fd, "newlink", 0)
    -> newlink is hardlink of symlink

  linkat(fd, "symlink", fd, "newlink", AT_SYMLINK_FOLLOW)
    -> newlink is hardlink of file

The value of AT_SYMLINK_FOLLOW is determined by the definition we already
use in glibc.
Signed-off-by: default avatarUlrich Drepper <drepper@redhat.com>
Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      45c9b11a
  39. 23 Jun, 2006 1 commit
  41. 20 Jun, 2006 1 commit
    • Amy Griffis's avatar
      [PATCH] log more info for directory entry change events · 9c937dcc
      Amy Griffis authored 
      
When an audit event involves changes to a directory entry, include
a PATH record for the directory itself.  A few other notable changes:

    - fixed audit_inode_child() hooks in fsnotify_move()
    - removed unused flags arg from audit_inode()
    - added audit log routines for logging a portion of a string

Here's some sample output.

before patch:
type=SYSCALL msg=audit(1149821605.320:26): arch=40000003 syscall=39 success=yes exit=0 a0=bf8d3c7c a1=1ff a2=804e1b8 a3=bf8d3c7c items=1 ppid=739 pid=800 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 comm="mkdir" exe="/bin/mkdir" subj=root:system_r:unconfined_t:s0-s0:c0.c255
type=CWD msg=audit(1149821605.320:26):  cwd="/root"
type=PATH msg=audit(1149821605.320:26): item=0 name="foo" parent=164068 inode=164010 dev=03:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=root:object_r:user_home_t:s0

after patch:
type=SYSCALL msg=audit(1149822032.332:24): arch=40000003 syscall=39 success=yes exit=0 a0=bfdd9c7c a1=1ff a2=804e1b8 a3=bfdd9c7c items=2 ppid=714 pid=777 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 comm="mkdir" exe="/bin/mkdir" subj=root:system_r:unconfined_t:s0-s0:c0.c255
type=CWD msg=audit(1149822032.332:24):  cwd="/root"
type=PATH msg=audit(1149822032.332:24): item=0 name="/root" inode=164068 dev=03:00 mode=040750 ouid=0 ogid=0 rdev=00:00 obj=root:object_r:user_home_dir_t:s0
type=PATH msg=audit(1149822032.332:24): item=1 name="foo" inode=164010 dev=03:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=root:object_r:user_home_t:s0
Signed-off-by: default avatarAmy Griffis <amy.griffis@hp.com>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      9c937dcc
  43. 05 Jun, 2006 1 commit
  45. 31 Mar, 2006 1 commit
  47. 27 Mar, 2006 1 commit
    • Ian Kent's avatar
      [PATCH] autofs4: nameidata needs to be up to date for follow_link · 051d3812
      Ian Kent authored 
      
In order to be able to trigger a mount using the follow_link inode method the
nameidata struct that is passed in needs to have the vfsmount of the autofs
trigger not its parent.

During a path walk if an autofs trigger is mounted on a dentry, when the
follow_link method is called, the nameidata struct contains the vfsmount and
mountpoint dentry of the parent mount while the dentry that is passed in is
the root of the autofs trigger mount.  I believe it is impossible to get the
vfsmount of the trigger mount, within the follow_link method, when only the
parent vfsmount and the root dentry of the trigger mount are known.

This patch updates the nameidata struct on entry to __do_follow_link if it
detects that it is out of date.  It moves the path_to_nameidata to above
__do_follow_link to facilitate calling it from there.  The dput_path is moved
as well as that seemed sensible.  No changes are made to these two functions.
Signed-off-by: default avatarIan Kent <raven@themaw.net>
Cc: Al Viro <viro@ftp.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      051d3812
  49. 25 Mar, 2006 2 commits
    • NeilBrown's avatar
      [PATCH] Honour AOP_TRUNCATE_PAGE returns in page_symlink · 7e53cac4
      NeilBrown authored 
      
As prepare_write, commit_write and readpage are allowed to return
AOP_TRUNCATE_PAGE, page_symlink should respond to them.
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7e53cac4
    • Oleg Drokin's avatar
      [PATCH] Missed error checking for intent's filp in open_namei(). · 4af4c52f
      Oleg Drokin authored 
      
It seems there is error check missing in open_namei for errors returned
through intent.open.file (from lookup_instantiate_filp).

If there is plain open performed, then such a check done inside
__path_lookup_intent_open called from path_lookup_open(), but when the open
is performed with O_CREAT flag set, then __path_lookup_intent_open is only
called with LOOKUP_PARENT set where no file opening can occur yet.

Later on lookup_hash is called where exact opening might take place and
intent.open.file may be filled.  If it is filled with error value of some
sort, then we get kernel attempting to dereference this error value as
address (and corresponding oops) in nameidata_to_filp() called from
filp_open().

While this is relatively simple to workaround in ->lookup() method by just
checking lookup_instantiate_filp() return value and returning error as
needed, this is not so easy in ->d_revalidate(), where we can only return
"yes, dentry is valid" or "no, dentry is invalid, perform full lookup
again", and just returning 0 on error would cause extra lookup (with
potential extra costly RPCs).

So in short, I believe that there should be no difference in error handling
for opening a file and creating a file in open_namei() and propose this
simple patch as a solution.
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4af4c52f
  51. 23 Mar, 2006 1 commit
  53. 20 Mar, 2006 2 commits
  55. 11 Mar, 2006 1 commit
  57. 24 Feb, 2006 1 commit
    • Ulrich Drepper's avatar
      [PATCH] flags parameter for linkat · c04030e1
      Ulrich Drepper authored 
      
I'm currently at the POSIX meeting and one thing covered was the
incompatibility of Linux's link() with the POSIX definition.  The name.
Linux does not follow symlinks, POSIX requires it does.

Even if somebody thinks this is a good default behavior we cannot change this
because it would break the ABI.  But the fact remains that some application
might want this behavior.

We have one chance to help implementing this without breaking the behavior.
 For this we could use the new linkat interface which would need a new
flags parameter.  If the new parameter is AT_SYMLINK_FOLLOW the new
behavior could be invoked.

I do not want to introduce such a patch now.  But we could add the
parameter now, just don't use it.  The patch below would do this.  Can we
get this late patch applied before the release more or less fixes the
syscall API?
Signed-off-by: default avatarUlrich Drepper <drepper@redhat.com>
Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c04030e1
  59. 07 Feb, 2006 1 commit