02 Mar, 2017
1 commit
-
We are going to split out of , which
will have to be picked up from other headers and a couple of .c files.Create a trivial placeholder file that just
maps to to make this patch obviously correct and
bisectable.Include the new header in the files that are going to need it.
Acked-by: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar
01 Feb, 2017
1 commit
-
To support unprivileged users mounting filesystems two permission
checks have to be performed: a test to see if the user allowed to
create a mount in the mount namespace, and a test to see if
the user is allowed to access the specified filesystem.The automount case is special in that mounting the original filesystem
grants permission to mount the sub-filesystems, to any user who
happens to stumble across the their mountpoint and satisfies the
ordinary filesystem permission checks.Attempting to handle the automount case by using override_creds
almost works. It preserves the idea that permission to mount
the original filesystem is permission to mount the sub-filesystem.
Unfortunately using override_creds messes up the filesystems
ordinary permission checks.Solve this by being explicit that a mount is a submount by introducing
vfs_submount, and using it where appropriate.vfs_submount uses a new mount internal mount flags MS_SUBMOUNT, to let
sget and friends know that a mount is a submount so they can take appropriate
action.sget and sget_userns are modified to not perform any permission checks
on submounts.follow_automount is modified to stop using override_creds as that
has proven problemantic.do_mount is modified to always remove the new MS_SUBMOUNT flag so
that we know userspace will never by able to specify it.autofs4 is modified to stop using current_real_cred that was put in
there to handle the previous version of submount permission checking.cifs is modified to pass the mountpoint all of the way down to vfs_submount.
debugfs is modified to pass the mountpoint all of the way down to
trace_automount by adding a new parameter. To make this change easier
a new typedef debugfs_automount_t is introduced to capture the type of
the debugfs automount function.Cc: stable@vger.kernel.org
Fixes: 069d5ac9ae0d ("autofs: Fix automounts by using current_real_cred()->uid")
Fixes: aeaa4a79ff6a ("fs: Call d_automount with the filesystems creds")
Reviewed-by: Trond Myklebust
Reviewed-by: Seth Forshee
Signed-off-by: "Eric W. Biederman"
04 Dec, 2016
2 commits
-
If an automount mount is clone(2)ed into a file system that is propagation
private, when it later expires in the originating namespace, subsequent
calls to autofs ->d_automount() for that dentry in the original namespace
will return ELOOP until the mount is umounted in the cloned namespace.Now that a struct path is available where needed use path_has_submounts()
instead of have_submounts() so we don't get false positives when checking
if a dentry is a mount point or contains mounts in the current namespace.Link: http://lkml.kernel.org/r/20161011053423.27645.91233.stgit@pluto.themaw.net
Signed-off-by: Ian Kent
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Omar Sandoval
Signed-off-by: Andrew Morton
Signed-off-by: Al Viro -
In order to use the functions path_is_mountpoint() and path_has_submounts()
autofs needs to pass a struct path in several places.Now change autofs4_wait() to take a struct path instead of a struct
dentry.Link: http://lkml.kernel.org/r/20161011053413.27645.84666.stgit@pluto.themaw.net
Signed-off-by: Ian Kent
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Omar Sandoval
Signed-off-by: Andrew Morton
Signed-off-by: Al Viro
01 Oct, 2016
1 commit
-
Seth Forshee reports that in 4.8-rcN some automounts are failing
because the requesting the automount changed.The relevant call path is:
follow_automount()
->d_automount
autofs4_d_automount
autofs4_mount_wait
autofs4_waitIn autofs4_wait wq_uid and wq_gid are set to current_uid() and
current_gid respectively. With follow_automount now overriding creds
uid that we export to userspace changes and that breaks existing
setups.To remove the regression set wq_uid and wq_gid from
current_real_cred()->uid and current_real_cred()->gid respectively.
This restores the current behavior as current->real_cred is identical
to current->cred except when override creds are used.Cc: stable@vger.kernel.org
Fixes: aeaa4a79ff6a ("fs: Call d_automount with the filesystems creds")
Reported-by: Seth Forshee
Tested-by: Seth Forshee
Signed-off-by: "Eric W. Biederman"
06 Aug, 2016
1 commit
-
Pull qstr constification updates from Al Viro:
"Fairly self-contained bunch - surprising lot of places passes struct
qstr * as an argument when const struct qstr * would suffice; it
complicates analysis for no good reason.I'd prefer to feed that separately from the assorted fixes (those are
in #for-linus and with somewhat trickier topology)"* 'work.const-qstr' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
qstr: constify instances in adfs
qstr: constify instances in lustre
qstr: constify instances in f2fs
qstr: constify instances in ext2
qstr: constify instances in vfat
qstr: constify instances in procfs
qstr: constify instances in fuse
qstr constify instances in fs/dcache.c
qstr: constify instances in nfs
qstr: constify instances in ocfs2
qstr: constify instances in autofs4
qstr: constify instances in hfs
qstr: constify instances in hfsplus
qstr: constify instances in logfs
qstr: constify dentry_init_security
29 Jul, 2016
1 commit
-
This changes the vfs dentry hashing to mix in the parent pointer at the
_beginning_ of the hash, rather than at the end.That actually improves both the hash and the code generation, because we
can move more of the computation to the "static" part of the dcache
setup, and do less at lookup runtime.It turns out that a lot of other hash users also really wanted to mix in
a base pointer as a 'salt' for the hash, and so the slightly extended
interface ends up working well for other cases too.Users that want a string hash that is purely about the string pass in a
'salt' pointer of NULL.* merge branch 'salted-string-hash':
fs/dcache.c: Save one 32-bit multiply in dcache lookup
vfs: make the string hashes salt the hash
21 Jul, 2016
1 commit
-
Signed-off-by: Al Viro
25 Jun, 2016
1 commit
-
__vfs_write() returns a negative value in a error case.
Link: http://lkml.kernel.org/r/20160616083108.6278.65815.stgit@pluto.themaw.net
Signed-off-by: Andrey Vagin
Signed-off-by: Ian Kent
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Jun, 2016
1 commit
-
We always mixed in the parent pointer into the dentry name hash, but we
did it late at lookup time. It turns out that we can simplify that
lookup-time action by salting the hash with the parent pointer early
instead of late.A few other users of our string hashes also wanted to mix in their own
pointers into the hash, and those are updated to use the same mechanism.Hash users that don't have any particular initial salt can just use the
NULL pointer as a no-salt.Cc: Vegard Nossum
Cc: George Spelvin
Cc: Al Viro
Signed-off-by: Linus Torvalds
16 Mar, 2016
6 commits
-
Use the standard pr_xxx() log macros directly for log prints instead of
the AUTOFS_XXX() macros.Signed-off-by: Ian Kent
Cc: Joe Perches
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Common kernel coding practice is to include the newline of log prints
within the log text rather than hidden away in a macro.To avoid introducing inconsistencies as changes are made change the log
macros to not include the newline.Signed-off-by: Ian Kent
Cc: Joe Perches
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Use the pr_*() print in AUTOFS_*() macros instead of printks and include
the module name in log message macros. Also use the AUTOFS_*() macros
everywhere instead of raw printks.Signed-off-by: Ian Kent
Cc: Joe Perches
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix some white space format errors.
Signed-off-by: Ian Kent
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The need for this is questionable but checkpatch.pl complains about the
line length and it's a straightfoward change.Signed-off-by: Ian Kent
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Try and make the coding style completely consistent throughtout the
autofs module and inline with kernel coding style recommendations.Signed-off-by: Ian Kent
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
16 Apr, 2015
1 commit
-
that's the bulk of filesystem drivers dealing with inodes of their own
Signed-off-by: David Howells
Signed-off-by: Al Viro
12 Apr, 2015
1 commit
-
Signed-off-by: Al Viro
24 Jan, 2014
1 commit
-
The PID and the TGID of the process triggering the mount are sent to the
daemon. Currently the global pid values are sent (ones valid in the
initial pid namespace) but this is wrong if the autofs daemon itself is
not running in the initial pid namespace.So send the pid values that are valid in the namespace of the autofs
daemon.The namespace to use is taken from the oz_pgrp pid pointer, which was
set at mount time to the mounting process' pid namespace.If the pid translation fails (the triggering process is in an unrelated
pid namespace) then the automount fails with ENOENT.Signed-off-by: Miklos Szeredi
Acked-by: Serge Hallyn
Cc: Eric Biederman
Acked-by: Ian Kent
Cc: Oleg Nesterov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Sep, 2013
1 commit
-
Don't drop ->wq_mutex before calling autofs4_notify_daemon() only to regain it
there. Besides being pointless, that opens a race window where autofs4_wait_release()
could've come and freed wq->name.name. And do the debugging printk in the "reused an
existing wq" case before dropping ->wq_mutex - the same reason...Signed-off-by: Al Viro
Acked-by: Ian Kent
02 Mar, 2013
1 commit
-
smatch analysis:
fs/autofs4/waitq.c:46 autofs4_catatonic_mode() info: redundant null check on wq->name.name calling kfree()
Signed-off-by: Tim Gardner
Signed-off-by: Ian Kent
Cc: autofs@vger.kernel.org
Signed-off-by: Linus Torvalds
15 Nov, 2012
1 commit
-
Use kuid_t and kgid_t in struct autofs_info and struct autofs_wait_queue.
When creating directories and symlinks default the uid and gid of
the mount requester to the global root uid and gid. autofs4_wait
will update these fields when a mount is requested.When generating autofsv5 packets report the uid and gid of the mount
requestor in user namespace of the process that opened the pipe,
reporting unmapped uids and gids as overflowuid and overflowgid.In autofs_dev_ioctl_requester return the uid and gid of the last mount
requester converted into the calling processes user namespace. When the
uid or gid don't map return overflowuid and overflowgid as appropriate,
allowing failure to find a mount requester to be distinguished from
failure to map a mount requester.The uid and gid mount options specifying the user and group of the
root autofs inode are converted into kuid and kgid as they are parsed
defaulting to the current uid and current gid of the process that
mounts autofs.Mounting of autofs for the present remains confined to processes in
the initial user namespace.Cc: Ian Kent
Acked-by: Serge Hallyn
Signed-off-by: Eric W. Biederman
27 Sep, 2012
1 commit
-
simplifies a bunch of callers...
Signed-off-by: Al Viro
28 Apr, 2012
1 commit
-
This reverts commit a32744d4abae24572eff7269bc17895c41bd0085.
While that commit was technically the right thing to do, and made the
x86-64 compat mode work identically to native 32-bit mode (and thus
fixing the problem with a 32-bit systemd install on a 64-bit kernel), it
turns out that the automount binaries had workarounds for this compat
problem.Now, the workarounds are disgusting: doing an "uname()" to find out the
architecture of the kernel, and then comparing it for the 64-bit cases
and fixing up the size of the read() in automount for those. And they
were confused: it's not actually a generic 64-bit issue at all, it's
very much tied to just x86-64, which has different alignment for an
'u64' in 64-bit mode than in 32-bit mode.But the end result is that fixing the compat layer actually breaks the
case of a 32-bit automount on a x86-64 kernel.There are various approaches to fix this (including just doing a
"strcmp()" on current->comm and comparing it to "automount"), but I
think that I will do the one that teaches pipes about a special "packet
mode", which will allow user space to not have to care too deeply about
the padding at the end of the autofs packet.That change will make the compat workaround unnecessary, so let's revert
it first, and get automount working again in compat mode. The
packetized pipes will then fix autofs for systemd.Reported-and-requested-by: Michael Tokarev
Cc: Ian Kent
Cc: stable@kernel.org # for 3.3
Signed-off-by: Linus Torvalds
26 Feb, 2012
1 commit
-
When the autofs protocol version 5 packet type was added in commit
5c0a32fc2cd0 ("autofs4: add new packet type for v5 communications"), it
obvously tried quite hard to be word-size agnostic, and uses explicitly
sized fields that are all correctly aligned.However, with the final "char name[NAME_MAX+1]" array at the end, the
actual size of the structure ends up being not very well defined:
because the struct isn't marked 'packed', doing a "sizeof()" on it will
align the size of the struct up to the biggest alignment of the members
it has.And despite all the members being the same, the alignment of them is
different: a "__u64" has 4-byte alignment on x86-32, but native 8-byte
alignment on x86-64. And while 'NAME_MAX+1' ends up being a nice round
number (256), the name[] array starts out a 4-byte aligned.End result: the "packed" size of the structure is 300 bytes: 4-byte, but
not 8-byte aligned.As a result, despite all the fields being in the same place on all
architectures, sizeof() will round up that size to 304 bytes on
architectures that have 8-byte alignment for u64.Note that this is *not* a problem for 32-bit compat mode on POWER, since
there __u64 is 8-byte aligned even in 32-bit mode. But on x86, 32-bit
and 64-bit alignment is different for 64-bit entities, and as a result
the structure that has exactly the same layout has different sizes.So on x86-64, but no other architecture, we will just subtract 4 from
the size of the structure when running in a compat task. That way we
will write the properly sized packet that user mode expects.Not pretty. Sadly, this very subtle, and unnecessary, size difference
has been encoded in user space that wants to read packets of *exactly*
the right size, and will refuse to touch anything else.Reported-and-tested-by: Thomas Meyer
Signed-off-by: Ian Kent
Signed-off-by: Linus Torvalds
14 Jan, 2012
1 commit
-
I don't know how I missed this obvious mistake when I
reviewed Als' patches, sorry.[ Quoting Al:
Grr... Note to self: do git status *and* git stash show -p
before git push. Nothing like "WTF? I'd fixed that braino"
feeling ;-/Al sent the same patch - it got broken in commit d668dc56631d:
"autofs4: deal with autofs4_write/autofs4_write races". ]Reported-and-tested-by: Dave Airlie
Signed-off-by: Ian Kent
Signed-off-by: Al Viro
Signed-off-by: Linus Torvalds
11 Jan, 2012
3 commits
-
Just serialize the actual writing of packets into pipe on
a new mutex, independent from everything else in the locking
hierarchy. As soon as something has started feeding a piece
of packet into the pipe to daemon, we *want* everything else
about to try the same to wait until we are done.Acked-by: Ian Kent
Signed-off-by: Al Viro -
we need to hold ->wq_mutex while we are forming the packet to send,
lest we have autofs4_catatonic_mode() setting wq->name.name to NULL
just as autofs4_notify_daemon() decides to memcpy() from it...We do have check for catatonic mode immediately after that (under
->wq_mutex, as it ought to be) and packet won't be actually sent,
but it'll be too late for us if we oops on that memcpy() from NULL...Fix is obvious - just extend the area covered by ->wq_mutex over
that switch and check whether it's catatonic *before* doing anything
else.Acked-by: Ian Kent
Signed-off-by: Al Viro -
We need to recheck ->catatonic after autofs4_wait() got ->wq_mutex
for good, or we might end up with wq inserted into queue after
autofs4_catatonic_mode() had done its thing. It will stick there
forever, since there won't be anything to clear its ->name.name.A bit of a complication: validate_request() drops and regains ->wq_mutex.
It actually ends up the most convenient place to stick the check into...Acked-by: Ian Kent
Signed-off-by: Al Viro
09 Aug, 2011
1 commit
-
The previous comit made the autofs4 debug printouts check types against
the printout format, and uncovered this bug:fs/autofs4/waitq.c:106:2: warning: format ‘%08lx’ expects type ‘long unsigned int’, but argument 4 has type ‘autofs_wqt_t’
which is due to the insane type for wait_queue_token. That thing should
be some fixed well-defined size (preferably just 'unsigned int' or
'u32') but for unexplained reasons it is randomly either 'unsigned long'
or 'unsigned int' depending on the architecture.For now, cast it to 'unsigned long' for printing, the way we do
elsewhere. Somebody else can try to explain the typedef mess.(There's a reason we don't support excessive use of typedefs in the
kernel: it's usually just a good way of confusing yourself).Signed-off-by: Linus Torvalds
25 Mar, 2011
1 commit
-
The autofs4_lock introduced by the rcu-walk changes has unnecessarily
broad scope. The locking is better handled by the per-autofs super
block lookup_lock.Signed-off-by: Ian Kent
Acked-by: David Howells
Signed-off-by: Al Viro
16 Jan, 2011
1 commit
-
It is possible for the check in wait.c:validate_request() to return
an incorrect result if the dentry that was mounted upon has changed
during the callback.Signed-off-by: Ian Kent
Signed-off-by: David Howells
Signed-off-by: Al Viro
07 Jan, 2011
2 commits
-
dcache_lock no longer protects anything. remove it.
Signed-off-by: Nick Piggin
-
The remaining usages for dcache_lock is to allow atomic, multi-step read-side
operations over the directory tree by excluding modifications to the tree.
Also, to walk in the leaf->root direction in the tree where we don't have
a natural d_lock ordering.This could be accomplished by taking every d_lock, but this would mean a
huge number of locks and actually gets very tricky.Solve this instead by using the rename seqlock for multi-step read-side
operations, retry in case of a rename so we don't walk up the wrong parent.
Concurrent dentry insertions are not serialised against. Concurrent deletes
are tricky when walking up the directory: our parent might have been deleted
when dropping locks so also need to check and retry for that.We can also use the rename lock in cases where livelock is a worry (and it
is introduced in subsequent patch).Signed-off-by: Nick Piggin
10 Jun, 2009
1 commit
-
The recent ->lookup() deadlock correction required the directory inode
mutex to be dropped while waiting for expire completion. We were
concerned about side effects from this change and one has been identified.I saw several error messages.
They cause autofs to become quite confused and don't really point to the
actual problem.Things like:
handle_packet_missing_direct:1376: can't find map entry for (43,1827932)
which is usually totally fatal (although in this case it wouldn't be
except that I treat is as such because it normally is).do_mount_direct: direct trigger not valid or already mounted
/test/nested/g3c/s1/ss1which is recoverable, however if this problem is at play it can cause
autofs to become quite confused as to the dependencies in the mount tree
because mount triggers end up mounted multiple times. It's hard to
accurately check for this over mounting case and automount shouldn't need
to if the kernel module is doing its job.There was one other message, similar in consequence of this last one but I
can't locate a log example just now.When checking if a mount has already completed prior to adding a new mount
request to the wait queue we check if the dentry is hashed and, if so, if
it is a mount point. But, if a mount successfully completed while we
slept on the wait queue mutex the dentry must exist for the mount to have
completed so the test is not really needed.Mounts can also be done on top of a global root dentry, so for the above
case, where a mount request completes and the wait queue entry has already
been removed, the hashed test returning false can cause an incorrect
callback to the daemon. Also, d_mountpoint() is not sufficient to check
if a mount has completed for the multi-mount case when we don't have a
real mount at the base of the tree.Signed-off-by: Ian Kent
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Jan, 2009
1 commit
-
- the type assigned at mount when no type is given is changed
from 0 to AUTOFS_TYPE_INDIRECT. This was done because 0 and
AUTOFS_TYPE_INDIRECT were being treated implicitly as the same
type.- previously, an offset mount had it's type set to
AUTOFS_TYPE_DIRECT|AUTOFS_TYPE_OFFSET but the mount control
re-implementation needs to be able distinguish all three types.
So this was changed to make the type setting explicit.- a type AUTOFS_TYPE_ANY was added for use by the re-implementation
when checking if a given path is a mountpoint. It's not really a
type as we use this to ask if a given path is a mountpoint in the
autofs_dev_ioctl_ismountpoint() function.- functions to set and test the autofs mount types have been added to
improve readability and make the type usage explicit.- the mount type is used from user space for the mount control
re-implementtion so, for consistency, all the definitions have
been moved to the user space include file include/linux/auto_fs4.h.Signed-off-by: Ian Kent
Signed-off-by: Jeff Moyer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Nov, 2008
1 commit
-
Wrap access to task credentials so that they can be separated more easily from
the task_struct during the introduction of COW creds.Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().
Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
sense to use RCU directly rather than a convenient wrapper; these will be
addressed by later patches.Signed-off-by: David Howells
Reviewed-by: James Morris
Acked-by: Serge Hallyn
Cc: Ian Kent
Cc: autofs@linux.kernel.org
Signed-off-by: James Morris
17 Oct, 2008
2 commits
-
Track the uid and gid of the last process to request a mount for on an
autofs dentry.[akpm@linux-foundation.org: fix tpyo in comment]
Signed-off-by: Ian Kent
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Usage of the AUTOFS_TYPE_* defines is a little confusing and appears
inconsistent.Signed-off-by: Ian Kent
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 Jul, 2008
1 commit
-
We have been seeing mount requests comming to the automount daemon for
keys of the form "/" which are lookups for
invalid map keys. But we can check for this in the kernel module and
return a fail immediately, without having to send a request to the daemon.It is possible to recognise these requests are invalid based on whether
the request dentry is negative and its relation to the autofs file system
root.For example, given the indirect multi-mount map entry:
idm1 \
/mm1 :/
/mm2 :/For a request to mount idm1, IS_ROOT((idm1)->d_parent) will be always be
true and the dentry may be negative. But directories idm1/mm1 and
idm1/mm2 will always be created as part of the mount request for idm1. So
any mount request within idm1 itself must have a positive dentry otherwise
the map key is invalid.In version 4 these multi-mount entries are all mounted and umounted as a
single request and in version 5 the directories idm1/mm1 and idm1/mm2 are
created and an autofs fs mounted on them to act as a mount trigger so the
above is also true.This also holds true for the autofs version 4 pseudo direct mount feature.
When this feature is used without the "--ghost" option automount(8) will
create internal submounts as we go down the map key paths which are
essentially normal indirect mounts for which the above holds. If the
"--ghost" option is given the directories for map keys are created at
daemon startup so valid map entries correspond to postive dentries in the
autofs fs.autofs version 5 direct mount maps are similar except that the IS_ROOT
check is not needed. This has been addressed in a previous patch tittled
"autofs4 - detect invalid direct mount requests".For example, given the direct multi-mount map entry:
/test/dm1 \
/mm1 :/
/mm2 :/An autofs fs is mounted on /test/dm1 as a trigger mount and when a mount
is triggered for /test/dm1, the multi-mount offset directories
/test/dm1/mm1 and /test/dm1/mm2 are created and an autofs fs is mounted on
them to act as mount triggers. So valid direct mount requests must always
have a positive dentry if they correspond to a valid map entry.Signed-off-by: Ian Kent
Acked-by: Jeff Moyer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds