summaryrefslogtreecommitdiffstats
path: root/security/apparmor/path.c
Commit message (Collapse)AuthorAgeFilesLines
* Apparmor: Use d_is_positive/negative() rather than testing dentry->d_inodeDavid Howells2015-02-221-1/+1
| | | | | | | | | Use d_is_positive(dentry) or d_is_negative(dentry) rather than testing dentry->d_inode as the dentry may cover another layer that has an inode when the top layer doesn't or may hold a 0,0 chardev that's actually a whiteout. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* apparmor: fix error code to failure message mapping for name lookupJohn Johansen2013-04-281-1/+1
| | | | | | | | | | -ESTALE used to be incorrectly used to indicate a disconnected path, when name lookup failed. This was fixed in commit e1b0e444 to correctly return -EACCESS, but the error to failure message mapping was not correctly updated to reflect this change. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Steve Beattie <sbeattie@ubuntu.com>
* apparmor: fix long path failure due to disconnected pathJohn Johansen2012-05-181-0/+2
| | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/955892 All failures from __d_path where being treated as disconnected paths, however __d_path can also fail when the generated pathname is too long. The initial ENAMETOOLONG error was being lost, and ENAMETOOLONG was only returned if the subsequent dentry_path call resulted in that error. Other wise if the path was split across a mount point such that the dentry_path fit within the buffer when the __d_path did not the failure was treated as a disconnected path. Signed-off-by: John Johansen <john.johansen@canonical.com>
* AppArmor: Move path failure information into aa_get_name and renameJohn Johansen2012-03-141-4/+18
| | | | | | | | | | | Move the path name lookup failure messages into the main path name lookup routine, as the information is useful in more than just aa_path_perm. Also rename aa_get_name to aa_path_name as it is not getting a reference counted object with a corresponding put fn. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
* AppArmor: Minor cleanup of d_namespace_path to consolidate error handlingJohn Johansen2012-03-141-10/+6
| | | | | Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
* AppArmor: Retrieve the dentry_path for error reporting when path lookup failsJohn Johansen2012-03-141-6/+9
| | | | | | | | | When __d_path and d_absolute_path fail due to the name being outside of the current namespace no name is reported. Use dentry_path to provide some hint as to which file was being accessed. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
* AppArmor: Fix error returned when a path lookup is disconnectedJohn Johansen2012-03-141-1/+1
| | | | | | | | | | | The returning of -ESATLE when a path lookup fails as disconnected is wrong. Since AppArmor is rejecting the access return -EACCES instead. This also fixes a bug in complain (learning) mode where disconnected paths are denied because -ESTALE errors are not ignored causing failures that can change application behavior. Signed-off-by: John Johansen <john.johansen@canonical.com>
* AppArmor: Fix the error case for chroot relative path name lookupJohn Johansen2012-02-271-3/+2
| | | | | | | | | When a chroot relative pathname lookup fails it is falling through to do a d_absolute_path lookup. This is incorrect as d_absolute_path should only be used to lookup names for namespace absolute paths. Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <kees@ubuntu.com>
* btrfs, nfs, apparmor: don't pull mnt_namespace.h for no reason...Al Viro2012-01-031-1/+0
| | | | | | | | it's not needed anymore; we used to, back when we had to do mount_subtree() by hand, complete with put_mnt_ns() in it. No more... Apparmor didn't need it since the __d_path() fix. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* fix apparmor dereferencing potentially freed dentry, sanitize __d_path() APIAl Viro2011-12-061-27/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __d_path() API is asking for trouble and in case of apparmor d_namespace_path() getting just that. The root cause is that when __d_path() misses the root it had been told to look for, it stores the location of the most remote ancestor in *root. Without grabbing references. Sure, at the moment of call it had been pinned down by what we have in *path. And if we raced with umount -l, we could have very well stopped at vfsmount/dentry that got freed as soon as prepend_path() dropped vfsmount_lock. It is safe to compare these pointers with pre-existing (and known to be still alive) vfsmount and dentry, as long as all we are asking is "is it the same address?". Dereferencing is not safe and apparmor ended up stepping into that. d_namespace_path() really wants to examine the place where we stopped, even if it's not connected to our namespace. As the result, it looked at ->d_sb->s_magic of a dentry that might've been already freed by that point. All other callers had been careful enough to avoid that, but it's really a bad interface - it invites that kind of trouble. The fix is fairly straightforward, even though it's bigger than I'd like: * prepend_path() root argument becomes const. * __d_path() is never called with NULL/NULL root. It was a kludge to start with. Instead, we have an explicit function - d_absolute_root(). Same as __d_path(), except that it doesn't get root passed and stops where it stops. apparmor and tomoyo are using it. * __d_path() returns NULL on path outside of root. The main caller is show_mountinfo() and that's precisely what we pass root for - to skip those outside chroot jail. Those who don't want that can (and do) use d_path(). * __d_path() root argument becomes const. Everyone agrees, I hope. * apparmor does *NOT* try to use __d_path() or any of its variants when it sees that path->mnt is an internal vfsmount. In that case it's definitely not mounted anywhere and dentry_path() is exactly what we want there. Handling of sysctl()-triggered weirdness is moved to that place. * if apparmor is asked to do pathname relative to chroot jail and __d_path() tells it we it's not in that jail, the sucker just calls d_absolute_path() instead. That's the other remaining caller of __d_path(), BTW. * seq_path_root() does _NOT_ return -ENAMETOOLONG (it's stupid anyway - the normal seq_file logics will take care of growing the buffer and redoing the call of ->show() just fine). However, if it gets path not reachable from root, it returns SEQ_SKIP. The only caller adjusted (i.e. stopped ignoring the return value as it used to do). Reviewed-by: John Johansen <john.johansen@canonical.com> ACKed-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Cc: stable@vger.kernel.org
* fs: take dcache_lock inside __d_pathChristoph Hellwig2010-10-251-2/+0
| | | | | | | | All callers take dcache_lock just around the call to __d_path, so take the lock into it in preparation of getting rid of dcache_lock. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* AppArmor: Drop hack to remove appended " (deleted)" stringJohn Johansen2010-09-081-27/+11
| | | | | | | | | The 2.6.36 kernel has refactored __d_path() so that it no longer appends " (deleted)" to unlinked paths. So drop the hack that was used to detect and remove the appended string. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
* apparmor: use task path helpersNick Piggin2010-08-181-7/+2
| | | | | | | apparmor: use task path helpers Signed-off-by: Nick Piggin <npiggin@kernel.dk> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* AppArmor: misc. base functions and definesJohn Johansen2010-08-021-0/+235
Miscellaneous functions and defines needed by AppArmor, including the base path resolution routines. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
OpenPOWER on IntegriCloud