linux-toradex.git/fs/namei.c, branch v3.6.5

VFS: don't do protected {sym,hard}links by default

2012-10-31T17:09:37+00:00

commit 561ec64ae67ef25cac8d72bb9c4bfc955edfd415 upstream.

In commit 800179c9b8a1 ("This adds symlink and hardlink restrictions to
the Linux VFS"), the new link protections were enabled by default, in
the hope that no actual application would care, despite it being
technically against legacy UNIX (and documented POSIX) behavior.

However, it does turn out to break some applications.  It's rare, and
it's unfortunate, but it's unacceptable to break existing systems, so
we'll have to default to legacy behavior.

In particular, it has broken the way AFD distributes files, see

  http://www.dwd.de/AFD/

along with some legacy scripts.

Distributions can end up setting this at initrd time or in system
scripts: if you have security problems due to link attacks during your
early boot sequence, you have bigger problems than some kernel sysctl
setting. Do:

	echo 1 > /proc/sys/fs/protected_symlinks
	echo 1 > /proc/sys/fs/protected_hardlinks

to re-enable the link protections.

Alternatively, we may at some point introduce a kernel config option
that sets these kinds of "more secure but not traditional" behavioural
options automatically.

Reported-by: Nick Bowler 
Reported-by: Holger Kiehl 
Cc: Kees Cook 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Al Viro 
Cc: Alan Cox 
Cc: Theodore Ts'o 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fs: prevent use after free in auditing when symlink following was denied

2012-10-21T16:32:42+00:00

commit ffd8d101a3a7d3f2e79deee1e342801703b6dc70 upstream.

Commit "fs: add link restriction audit reporting" has added auditing of failed
attempts to follow symlinks. Unfortunately, the auditing was being done after
the struct path structure was released earlier.

Signed-off-by: Sasha Levin 
Signed-off-by: Al Viro 
Cc: Dave Jones 
Signed-off-by: Greg Kroah-Hartman

fs: fix fs/namei.c kernel-doc warnings

2012-08-22T14:30:10+00:00

Fix kernel-doc warnings in fs/namei.c:

Warning(fs/namei.c:360): No description found for parameter 'inode'
Warning(fs/namei.c:672): No description found for parameter 'nd'

Signed-off-by: Randy Dunlap 
Cc:	Alexander Viro 
Cc:	linux-fsdevel@vger.kernel.org
Signed-off-by: Al Viro

vfs: fix propagation of atomic_open create error on negative dentry

2012-08-16T17:29:09+00:00

If ->atomic_open() returns -ENOENT, we take care to return the create
error (e.g., EACCES), if any.  Do the same when ->atomic_open() returns 1
and provides a negative dentry.

This fixes a regression where an unprivileged open O_CREAT fails with
ENOENT instead of EACCES, introduced with the new atomic_open code.  It
is tested by the open/08.t test in the pjd posix test suite, and was
observed on top of fuse (backed by ceph-fuse).

Signed-off-by: Sage Weil 
Signed-off-by: Miklos Szeredi

vfs: pass right create mode to may_o_create()

2012-08-15T11:01:24+00:00

Pass the umask-ed create mode to may_o_create() instead of the original one.

Signed-off-by: Miklos Szeredi 
Tested-by: Richard W.M. Jones

vfs: atomic_open(): fix create mode usage

2012-08-15T11:01:24+00:00

Don't mask S_ISREG off the create mode before passing to ->atomic_open().  Other
methods (->create, ->mknod) also get the complete file mode and filesystems
expect it.

Reported-by: Steve 
Reported-by: Richard W.M. Jones 
Signed-off-by: Miklos Szeredi 
Tested-by: Richard W.M. Jones

fs: Push mnt_want_write() outside of i_mutex

2012-07-30T21:02:49+00:00

Currently, mnt_want_write() is sometimes called with i_mutex held and sometimes
without it. This isn't really a problem because mnt_want_write() is a
non-blocking operation (essentially has a trylock semantics) but when the
function starts to handle also frozen filesystems, it will get a full lock
semantics and thus proper lock ordering has to be established. So move
all mnt_want_write() calls outside of i_mutex.

One non-trivial case needing conversion is kern_path_create() /
user_path_create() which didn't include mnt_want_write() but now needs to
because it acquires i_mutex.  Because there are virtual file systems which
don't bother with freeze / remount-ro protection we actually provide both
versions of the function - one which calls mnt_want_write() and one which does
not.

[AV: scratch the previous, mnt_want_write() has been moved to kern_path_create()
by now]

Signed-off-by: Jan Kara 
Signed-off-by: Al Viro

simplify lookup_open()/atomic_open() - do the temporary mnt_want_write() early

2012-07-30T20:53:35+00:00

The write ref to vfsmount taken in lookup_open()/atomic_open() is going to
be dropped; we take the one to stay in dentry_open().  Just grab the temporary
in caller if it looks like we are going to need it (create/truncate/writable open)
and pass (by value) "has it succeeded" flag.  Instead of doing mnt_want_write()
inside, check that flag and treat "false" as "mnt_want_write() has just failed".
mnt_want_write() is cheap and the things get considerably simpler and more robust
that way - we get it and drop it in the same function, to start with, rather
than passing a "has something in the guts of really scary functions taken it"
back to caller.

Signed-off-by: Al Viro

fix O_EXCL handling for devices

2012-07-30T07:50:30+00:00

O_EXCL without O_CREAT has different semantics; it's "fail if already opened",
not "fail if already exists".  commit 71574865 broke that...

Signed-off-by: Al Viro

fs: add link restriction audit reporting

2012-07-29T17:43:08+00:00

Adds audit messages for unexpected link restriction violations so that
system owners will have some sort of potentially actionable information
about misbehaving processes.

Signed-off-by: Kees Cook 
Signed-off-by: Al Viro