Karel Zak [Thu, 5 Jan 2012 18:32:26 +0000 (13:32 -0500)]
mount.nfs: don't overwrite mount options from /etc/nfsmount.conf
The libmount (as well as mount(8)) ignores mount options from command
line if running in restricted mode (suid, non-root-user) and all
options are read from fstab only.
It means that all options are replaced with stuff from fstab,
including mount options from nfsmount.conf. This is bug.
We have to apply fstab and then nfsmount.conf.
Signed-off-by: Karel Zak <kzak@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Steve Dickson [Mon, 5 Dec 2011 14:48:46 +0000 (09:48 -0500)]
mount.nfs: Background mounts failing on time out errors.
Mounting with the "-o v3,bg,proto=udp" options will
fail, instead of retrying, when the server is down.
The reason being nfs_rewrite_pmap_mount_options()
does not interrupt RPC timeouts correctly.
Steve Dickson [Mon, 14 Nov 2011 14:47:21 +0000 (09:47 -0500)]
nfsidmap: Added -v and -t flags
To aid in debugging, the -v flag can now be specified,
multiple time, on the command line to enable verbose
logging in both the nfsidmap command and libnfsidmap
library routines.
Also converted the timeout argument to use a -t flag.
Yang Bai [Tue, 18 Oct 2011 15:53:11 +0000 (11:53 -0400)]
mount.nfs: Mount should really return from errno test
We should only try next address family if we meet ECONNREFUSED or
EHOSTUNREACH for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
Before, only a break in swich can not make the program out of for loop.
Signed-off-by: Yang Bai <hamo.by@gmail.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Luca Giuzzi [Tue, 4 Oct 2011 17:35:06 +0000 (13:35 -0400)]
rpc.idmapd: Dies with 'I/O possible'
We have had problems on some of our machines (all Fedora 14), where
rpc.idmapd used to die with an `I/O possible' message at (basically)
random times. A strace suggested the issue being in nfsopen() where a
signal type is reset before notification is disabled; a signal at just
the right time might be the cause of the problem; see
https://bugzilla.redhat.com/show_bug.cgi?id=684308
Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Luk Claes [Mon, 3 Oct 2011 12:42:20 +0000 (08:42 -0400)]
blkmapd: Use getconf(_SC_PAGE_SIZE)
PAGE_SIZE is not exported by all architectures as it is not fixed: it
can depend on the model of the machine. So it's better to query the
system configuration for the actual page size on the machine.
Signed-off-by: Luk Claes <luk@debian.org> Signed-off-by: Steve Dickson <steved@redhat.com>
Steve Dickson [Wed, 21 Sep 2011 18:05:07 +0000 (14:05 -0400)]
mountstats: Breaks on 3.1 kernels
mountstats depend on all devices entries in /proc/self/mountstats
to start with the word 'device'. With 3.1 kernels, NFS entries
start with the actual device (i.e. server:/export) not
the word 'device'. This change confused mountstats parsing.
Steve Dickson [Wed, 21 Sep 2011 17:52:49 +0000 (13:52 -0400)]
nfsiostat: Breaks on 3.1 kernels
nfsiostat depend on all devices entries in /proc/self/mountstats
to start with the word 'device'. With 3.1 kernels, NFS entries
start with the actual device (i.e. server:/export) not
the word 'device'. This change confused nfsiostat parsing.
The decoded octal will always be positive and (char) -1 is negative. Any
field containing an encoded octal will be rejected.
As the encoded value should be an unsigned char, fix the check to reject
all values > (unsigned char) -1 = UCHAR_MAX, as this indicate an error
in the encoding.
Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de> Signed-off-by: Steve Dickson <steved@redhat.com>
Steve Dickson [Tue, 20 Sep 2011 16:52:46 +0000 (12:52 -0400)]
statd: Decouple statd's state directory from the NFS state directory
To allow greater flexibility to where statd's state is kept,
statd's state path can now be decoupled from the normal
NFS state directory.
In configure.ac, the NSM_DEFAULT_STATEDIR definition will now define
the path to where the state information is kept. The default
value, /var/lib/nfs, can be redefined with the --with-statdpath
flag.
Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
J. Bruce Fields [Tue, 20 Sep 2011 11:40:15 +0000 (07:40 -0400)]
nfsd: allow choosing server 41 support at runtime
In the case where -N 4.1 is left off the commandline, the current code
explicitly turns it on or off anyway, depending on configure options.
Instead, just leave 4.1 support alone. This allows a user to add an
"echo +4.1 >/proc/fs/nfsd/versions" to their init scripts, if they want.
Otherwise they will get the kernel's default (currently to leave 4.1
off, as long as 4.1 support is experimental).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com>
Chuck Lever [Mon, 19 Sep 2011 18:23:54 +0000 (14:23 -0400)]
sm-notify: sm-notify leaves monitor records in sm.bak
sm-notify fails to remove monitor records from sm.bak when it has
finally notified a host. This is because of a recent change to send
two SM_NOTIFY requests for each monitored peer: one with the local
host's FQDN, and one with an unqualified version of same. This was
commit baa41b2c: "sm-notify: Send fully-qualified and unqualified
mon_names" (March 19, 2010).
Because of the March 2010 commit, sm-notify modifies the "my_name"
string during notification, but then uses this modified string to try
to find the monitor record to remove. Of course the search for the
record fails. So a persistent monitor record is left in sm.bak.
Aside from leaving trash around, this causes the same hosts to be
notified after every reboot, even if they successfully responded to
the previous SM_NOTIFY and they had no contact with us during the last
boot.
I also noticed that the trick of truncating the argument of SM_NOTIFY
doesn't work at all if a substitute "my_name" was specified via the "-v"
command line option. This patch attempts to address that as well.
sm-notify should preserve the original my_name string so that
nsm_delete_host() can find the correct monitor record to delete. Also
add some degree of protection to the mon_name and my_name strings in
each nsm_host record to prevent a future change from breaking this
dependency.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Chuck Lever [Mon, 19 Sep 2011 18:20:25 +0000 (14:20 -0400)]
sm-notify: Avoid extra rpcbind queries
The logic in notify_host() watches the host->retries counter to see if
progress is not being made. If progress stalls, notify_host() tries
another IP address. This means sm-notify will generate a fresh
rpcbind query.
After an RPC succeeds, be sure to reset host->retries so sm-notify
doesn't start walking down the host's addrinfo list when we _are_
making progress. In the common case, if the host responds, we avoid
extra rpcbind queries and send all requests for the host to the same
IP address.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Chuck Lever [Mon, 19 Sep 2011 18:18:47 +0000 (14:18 -0400)]
sm-notify: Use correct retransmit timeout when sending a fresh RPC
An RPC retransmit timeout should start out the same for each new RPC
request. Don't increase the retransmit timeout after receiving the
reply to the rpcbind query.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Chuck Lever [Mon, 19 Sep 2011 18:10:08 +0000 (14:10 -0400)]
nfsumount: Squelch compiler warning
nfsumount.c: In function nfs_umount_is_vers4:
nfsumount.c:164: warning: conversion to int from size_t may alter its value
nfsumount.c:173: warning: conversion to ?size_t? from int may change the sign of the result
Chuck Lever [Mon, 19 Sep 2011 18:02:10 +0000 (14:02 -0400)]
configure.ac: Fix help string for --with-statedir= option
The help string for --with-statedir attempts to show "/var/lib/nfs" in
square brackets, but they don't appear on my system (Fedora 13). Use
the AC_HELP_STRING macro to display the help string properly, like all
the other "with" and "enable" options specified in our configure.ac.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Mike Frysinger [Thu, 1 Sep 2011 15:34:25 +0000 (11:34 -0400)]
exportfs: do not warn if /etc/exports.d/ does not exist
It isn't uncommon for /etc/exports.d/ to not exist, and imo, it's not
that big of a deal as often times, a simple /etc/exports is sufficient.
So silently skip the case where the dir is missing.
Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Steve Dickson <steved@redhat.com>
It looks like the existing algorithm for verifying the passed-in bind
address is as broken as statd_matchhostname() used to be: for IP
addresses, AI_CANONNAME is useless. We need to have getnameinfo(3) or
equivalent in there.
Clean up: extract the logic that verifies the command line bind
address into its own function, and make it handle canonical name
lookup correctly.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Same change as statd_matchhostname() is necessary for the logic in
exportfs.
Recall that these are "separate but nearly equal" because the exportfs
version requires extra expensive string checking that would be onerous
for statd.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
The job of statd_matchhostname() is to work hard at matching two
hostnames or presentation IP addresses that may refer to the same
host.
statd_matchhostname() turns the hostname of the local system into a
list of addresses containing only the loopback address. The actual
DNS registered address of the system does not appear in that list.
Presentation IP addresses, on the other hand, are soundly ignored by
the AI_CANONNAME option of getaddrinfo(3). The ai_canonname string
that is returned is just the same presentation IP address. And the
resulting list of addresses contains just that IP address.
So if the DNS registered IP address of the local host is passed in as
one argument, and the local hostname is passed as the other argument,
statd_matchhostname() whiffs and believes there is no match. To fix
this, the logic needs to be smarter about deriving a hostname from an
IP address.
This appears to cause no end of trouble: monitor records pile up in
/var/lib/nfs/sm and sm.bak, notifications are missed, and so on. This
has likely been around since commit cbd3a131 "statd: Introduce statd
version of matchhostname()" (Jan 14, 2010).
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Chuck Lever [Mon, 29 Aug 2011 17:13:15 +0000 (13:13 -0400)]
sm-notify: Disable syslog messages when debugging is enabled
statd's "-F" flag disables syslog output, and specifies sm-notify's
"-d" option when it runs it. sm-notify's "-d" option should therefore
also disable syslog output.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
NeilBrown [Mon, 29 Aug 2011 16:56:17 +0000 (12:56 -0400)]
pdate addres for Free Software Foundation
License texts contain multiple address for FSF, some wrong.
So update them and replace COPYING file with
http://www.gnu.org/licenses/gpl-2.0.txt
which has a few changes to preamble and commentary.
Also remove extra COPYING file from utils/statd/
Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
Ian Kent [Mon, 29 Aug 2011 16:29:36 +0000 (12:29 -0400)]
umount.nfs: fix nfs4 check
From: Ian Kent <ikent@redhat.com>
nfs_umount_is_vers4() doesn't take acount of the escaping of characters
seen in /proc/mounts and /etc/mtab as the functions in fstab.c do. This
leads to an inability to umount a mount containing any of these escaped
characters (like spaces).
This patch changes nfs_umount_is_vers4() to use functions in fstab.c and
adds a function to fstab.c to read /proc/mounts specifically, as it was
used for the check in nfs_umount_is_vers4() previously.
Signed-off-by: Ian Kent <ikent@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Luk Claes [Mon, 29 Aug 2011 15:46:17 +0000 (11:46 -0400)]
exports.man: Fix comment syntax
Using three single-quotes for a comment sort of works because it
results in invoking a nonexistent macro, but it results in a huge
number of warnings when trying to validate the man page.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Luk Claes <luk@debian.org> Signed-off-by: Steve Dickson <steved@redhat.com>
Max Matveev [Tue, 16 Aug 2011 11:57:43 +0000 (07:57 -0400)]
mount.nfs: submarvellous messages from mount.nfs
Consider a setup where mountd on the server is controlled via
tcp_wrappers (usual RHEL setup) and will not process calls from a
particular client because of something in /etc/hosts.deny.
When such client attempts to do v3 mount, the error message printed
by mount.nfs is misleading.
This patch changes that error message from:
mount.nfs: Argument list too long
to
mount.nfs: access denied by server while mounting server:/export
Chuck Lever [Wed, 3 Aug 2011 17:22:52 +0000 (13:22 -0400)]
rpc.statd: Bind downcall socket to loopback address
In the past, rpc.statd posted SM_NOTIFY requests using the same socket
it used for sending downcalls to the kernel. To receive replies from
remote hosts, the socket was bound to INADDR_ANY.
With commit f113db52 "Remove notify functionality from statd in
favour of sm-notify" (Mar 20, 2007), the downcall socket is no longer
used for sending requests to remote hosts. However, the downcall
socket is still bound to INADDR_ANY.
Thus a remote host can inject data on this socket since it is an
unconnected UDP socket listening for RPC replies. Thanks to f113db52,
the port number of this socket is no longer controlled by a command
line option, making it difficult to firewall.
We have demonstrated that data injection on this socket can result in
a DoS by causing rpc.statd to consume CPU and log bandwidth, but so
far we have not found a breach.
To prevent unwanted data injection, bind this socket to the loopback
address.
Fixed the usage of strcmp in the duplicate check in insert groups.
Fixes an issue with showmount and other commands that required
the group information.
Signed-off-by: Matthew Treinish <treinish@linux.vnet.ibm.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Mi Jinlong [Wed, 3 Aug 2011 16:52:48 +0000 (12:52 -0400)]
rpc.mountd: let mountd consult /etc/services for port
At RHEL, if user set port for mountd at /etc/services as
"mount 12345/tcp", mountd should be bind to 12345, but the
latest nfs-utils, mountd get a rand port, not 12345.
This patch make sure mountd be bind to the port which was set
at /etc/service.
Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Statd should always 'chdir' to its state directory.
s statd can be started by 'mount' which can sometimes be run by a
normal user, the current-working-directory could be anything. In
partcular it could be in a mounted filesystem. As 'statd' continues
running as a daemon it could keep prevent that filesystem from being
unmounted.
statd does currently 'chdir' to the state directory, but only if the
state directory is not owned by root. This is wrong - it should check
for root after the chdir, not before.
So swap the two if statements around.
Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
Kevin Coffman [Thu, 21 Jul 2011 18:16:59 +0000 (14:16 -0400)]
svcgssd: use correct defaults in call to gss_set_allowable_enctypes
For the window of kernels between 2.6.35 (when the support
for newer encryption was added) and 2.6.39 (when the ability
to read the supported enctypes from the kernel was added),
use a default of all enctypes when the kernel supported
enctypes file cannot be read.
For kernels before 2.6.35, continue to use a default of
only DES enctypes.
Note that the version of Kerberos must also support the use of
gss_set_allowable_enctypes for service-side negotiations.
See also: http://bugzilla.redhat.com/show_bug.cgi?id=719776
Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com>
Michael Guntsche [Wed, 13 Jul 2011 17:26:57 +0000 (13:26 -0400)]
nfsidmap: Manpage corrections
I recently upgraded to 1.2.4 to use the new nfsidmap feature. While
following the manpage and the kernel documentation I noticed a
difference. Kernel docs mention key TYPE id_resolver while the manpage
states nfs_idmap. The following patch changes the manpage to the proper
type.
mount.nfs: Do not segfault because of kernel version
mount.nfs segfaults if kernel version number does not contain
at least 3 components delimited with a dot.
Avoid this by matching up to three unsigned integers inialised
to zero, separated by dots.
A version that does not start with an integer is probably a future
version where the versioning evolved to another scheme.
Return UINT_MAX which is guaranteed to be higher than existing
versions. This would also make it possible to easily identify
versions that do not start with an integer.
Signed-off-by: Luk Claes <luk@debian.org> Signed-off-by: Steve Dickson <steved@redhat.com>
Kevin Coffman [Thu, 30 Jun 2011 15:13:38 +0000 (11:13 -0400)]
Add requirement for newer libgssglue for svcgssd -n option
SNAFU. This came to my attention minutes after 1.2.4 was
released...
Changes in commit d6c1b35c require that gss_acquire_cred()
is now called when the "-n" option is used. This requires an
updated libgssglue which properly handles name GSS_C_NO_NAME
as input to gss_import_name()/gss_acquire_cred().
Add a requirement for the newer version.
Without the newer libgssglue, when svcgssd is started with "-n"
you will see the error message, "ERROR: GSS-API: error in
gss_acquire_cred(): GSS_S_BAD_NAME (An invalid name was supplied)
- Unknown error"
Prem Karat [Tue, 28 Jun 2011 15:53:40 +0000 (11:53 -0400)]
mount.nfs: Don't hard code source and destination
Currently souce and destination parameters should be passed as first and
second paramter while using mount.nfs. This patch allows them to be passed
anywhere while mounting.
Current functionality is
mount.nfs source destn -o <options>
This patch will allow to do this
mount.nfs -o <options> source destn
or
mount.nfs -o <options> source -o <options> destn
Signed-off-by: Prem Karat <prem.karat@linux.vnet.ibm.com> Signed-off-by: Steve Dickson <steved@redhat.com>
NeilBrown [Tue, 28 Jun 2011 15:36:31 +0000 (11:36 -0400)]
mount: improve signal management when locking mtab
As mount.nfs can run setuid it must be careful about how the user can
interact with in. In particular it needs to ensure it does not
respond badly to any signals that the user might be able to generate.
This is particularly an issue while updating /etc/mtab (when that is
not linked to /proc/mounts). If the user can generate a signal which
kills mount.nfs while /etc/mtab is locked, then it will leave the file
locked, and could possibly corrupt mtab (particularly if 'ulimit 1'
was previously issued).
Currently lock_mtab does set some handlers for signals, but not
enough. It arranges for every signal up to (but not including)
SIGCHLD to cause mount.nfs to unlock mdadm promptly exit ... even if
the default behaviour would be to ignore the signal. SIGALRM is
handled specially, and signals after SIGCHLD are left with their
default behaviour. This includes for example SIGXFSZ which can be
generated by the user running "ulimit 1".
So: change this so that some signals are left unchanged, SIGALRM is
handled as required, and all signals that the user can generate are
explicitly ignored.
The remainder still cause mount.nfs to print a message, unlock mtab, and
exit.
Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
J. Bruce Fields [Mon, 27 Jun 2011 16:30:36 +0000 (12:30 -0400)]
mountd: gather fsid information into one struct
A large part of nfsd_fh() is concerned with extracting
fsid-type-specific information from the fsid, then matching that
information with information from the export list and the filesystem.
Moving all that information into one struct will allow some further
simplifications.
Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
J. Bruce Fields [Mon, 27 Jun 2011 16:29:51 +0000 (12:29 -0400)]
mountd: prefer explicit subexports over crossmnt parents
If a parent is exported with crossmnt, and if a child is also explicitly
exported, then both exports could potentially produce matches in this
loop; that isn't a bug.
Instead of warning and ignoring the second match we find, we should
instead prefer whichever export is deeper in the tree, so that
children's options can override those of their parents.
Reported-by: Olga Kornievskaia <aglo@citi.umich.edu> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
James Pearson [Wed, 22 Jun 2011 19:51:47 +0000 (15:51 -0400)]
nfs-utils: remove possibly false statement from exports.man
A very minor change suggested by J. Bruce Fields <bfields@fieldses.org>
to remove the statement that exporting to a single host or IP address is
the "most common format" - as it probably isn't.
Signed-off-by: James Pearson <james-p@moving-picture.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Jeff Layton [Wed, 22 Jun 2011 19:51:02 +0000 (15:51 -0400)]
manpage: add info about IPv6 configuration to exports(5)
The parts of the exports(5) manpage that discuss IP addressing neglect
IPv6 configuration. Update to include info on how to export to IPv6
subnets and addresses, and add a line demonstrating that to the EXAMPLE
section.
Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Jeff Layton [Wed, 22 Jun 2011 18:51:38 +0000 (14:51 -0400)]
nfs: fix host_reliable_addrinfo
According to Neil Brown:
The point of the word 'reliable' is to check that the name we get
really does belong to the host in question - ie that both the
forward and reverse maps agree.
But the new code doesn't do that check at all. Rather it simply
maps the address to a name, then discards the address and maps the
name back to a list of addresses and uses that list of addresses as
"where the request came from" for permission checking.
This bug is exploitable via the following scenario and could allow an
attacker access to data that they shouldn't be able to access.
Suppose you export a filesystem to some subnet or FQDN and also to a
wildcard or netgroup, and I know the details of this (maybe
showmount -e tells me) Suppose further that I can get IP packets to
your server..
Then I create a reverse mapping for my ipaddress to a domain that I
own, say "black.hat.org", and a forward mapping from that domain to
my IP address, and one of your IP addresses.
Then I try to mount your filesystem. The IP address gets correctly
mapped to "black.hat.org" and then mapped to both my IP address and
your IP address.
Then you search through all of your exports and find that one of the
addresses: yours - is allowed to access the filesystem.
So you create an export based on the addrinfo you have which allows
my IP address the same access as your IP address.
Fix this by instead using the forward lookup of the hostname just to
verify that the original address is in the list. Then do a numeric
lookup using the address and stick the hostname in the ai_canonname.
Reviewed-by: NeilBrown <neilb@suse.de> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Pavel Shilovsky [Tue, 7 Jun 2011 17:18:13 +0000 (13:18 -0400)]
mountd: Fix missing varialble assignment in auth_unix_gid
When we get into auth_unix_gid at the second time, groups_len
is not 0 and ngroups variable leave as 0. Then we use ngroups
in getgrouplist that fails in this case. This patch fixes it.
Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by: Steve Dickson <steved@redhat.com>
NeilBrown [Mon, 23 May 2011 12:23:51 +0000 (08:23 -0400)]
supress socket error when address family is not supported
From: Suresh Jayaraman <sjayaraman@suse.de>
It was observed that when ipv6 module was not loaded and cannot be auto-loaded,
when starting NFS server, the following error occurs:
"rpc.nfsd: unable to create inet6 TCP socket: errno 97 (Address
family not supported by protocol)"
This is obviously a true message, but does not represent an "error" when ipv6
is not enabled. Rather, it is an expected condition. As such, it can be
confusing / misleading / distracting to display it in this scenario.
This patch instead of throwing error when a socket call fails with
EAFNOSUPPORT, makes it as a NOTICE.
Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
NeilBrown [Mon, 23 May 2011 12:19:57 +0000 (08:19 -0400)]
Remove risk of nfs_addmntent corrupting mtab
nfs_addmntent is used to append directly to /etc/mtab.
If the write partially fail, e.g. due to RLIMIT_FSIZE,
truncate back to original size and return an error.
See also https://bugzilla.redhat.com/show_bug.cgi?id=697975
(CVE-2011-1749) CVE-2011-1749 nfs-utils: mount.nfs fails to anticipate RLIMIT_FSIZE
Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Steve Dickson <steved@redhat.com>
Ben Myers [Mon, 23 May 2011 12:07:00 +0000 (08:07 -0400)]
exportfs: getexportent interprets -test-client- as default options
With commit 1374c3861abdc66f3a1410e26cc85f86760b51dd Neil added a
-test-client- export to test the exportability of filesystems when exportfs
is run. When using the old cache controls (i.e. /proc/fs/nfsd is not
mounted) exportfs will read /proc/fs/nfs/exports to process existing
exports and find these test client entries. The dash at the beginning of
-test-client- will be cause getexportent to look for default options in the
rest of the string, which test-client- will not match:
This patch resolves that problem (as Steve suggested) by not processing any
default options if we are reading the list of existing exports from the
kernel. Default options are converted to individual exports by exportfs so
the kernel won't have any regardless.
Signed-off-by: Ben Myers <bpm@sgi.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Sean Finney [Tue, 19 Apr 2011 15:04:35 +0000 (11:04 -0400)]
nfs-utils: Increase the stdio file buffer size for procfs files
Previously, when writing to /proc/net/rpc/*/channel, if a cache line
were larger than the default buffer size (likely 1024 bytes), mountd
and svcgssd would split writes into a number of buffer-sized writes.
Each of these writes would get an EINVAL error back from the kernel
procfs handle (it expects line-oriented input and does not account for
multiple/split writes), and no cache update would occur.
When such behavior occurs, NFS clients depending on mountd to finish
the cache operation would block/hang, or receive EPERM, depending on
the context of the operation. This is likely to happen if a user is a
member of a large (~100-200) number of groups.
Instead, every fopen() on the procfs files in question is followed by
a call to setvbuf(), using a per-file dedicated buffer of
RPC_CHAN_BUF_SIZE length.
Really, mountd should not be using stdio-style buffered file operations
on files in /proc to begin with. A better solution would be to use
internally managed buffers and calls to write() instead of these stdio
calls, but that would be a more extensive change; so this is proposed
as a quick and not-so-dirty fix in the meantime.
Signed-off-by: Sean Finney <sean.finney@sonyericsson.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Sean Finney [Tue, 19 Apr 2011 15:05:47 +0000 (11:05 -0400)]
mountd: Use a dynamic buffer for storing lists of gid's
Previously, in auth_unix_gid, group lists were stored in an array of
hard-coded length 100, and in the situation that the group lists for a
particular call were too large, the array was swapped with a dynamically
allocated/freed buffer. For environments where users are commonly in
a large number of groups, this isn't an ideal approach.
Instead, use malloc/realloc to grow the list on an as-needed basis.
Signed-off-by: Sean Finney <sean.finney@sonyericsson.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Karel Zak [Wed, 6 Apr 2011 16:39:21 +0000 (12:39 -0400)]
mount: add --enable-libmount-mount
This patch allows to link mount.nfs with libmount from util-linux >=
v2.19. The new libmount based code is enabled by CONFIG_LIBMOUNT and
is stored in mount_libmount.c. The old code is not affected by this
change.
The libmount does not have officially stable API yet, so the
--enable-libmount-mount is marked as experimental in the configure
help output.
The ./configure option is the same as we use in util-linux to enable
support for libmount in mount(8).
The addr= (and some other options necessary for remount/umount) are
stored to /etc/mtab or to /dev/.mount/utab. The utab file is *private*
libmount file. It's possible that some mount options (for example
user=) will be moved to kernel, so the utab will not be necessary.
About libmount:
* supports systems without and with regular /etc/mtab
* does not store VFS and FS mount options in userspace
* manages user= option and evaluate permissions
* parses VFS mount options and generate MS_* flags
* parses /etc/{fstab,mtab}, /proc/mounts or /proc/self/mountinfo
* long-term goal is to use the same code in all mount.<type> helpers
Note, use
LIBMOUNT_DEBUG=0xffff mount.nfs foo:/path /path
to debug the library.
On systems with util-linux v2.19 the findmnt(8) command uses libmount
to list all/selected mount points:
$ findmnt /path
$ findmnt --mtab /path
the --mtab appends userspace mount options (e.g. user=) to the output.
CC: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Karel Zak <kzak@redhat.com> Signed-off-by: Steve Dickson <steved@redhat.com>
Kevin Coffman [Wed, 6 Apr 2011 15:25:03 +0000 (11:25 -0400)]
nfs-utils: Add support to svcgssd to limit the negotiated enctypes
Recent versions of Kerberos libraries negotiate and use
an "acceptor subkey". This negotiation does not consider
that a service may have limited the encryption keys in its
keytab. A patch (http://src.mit.edu/fisheye/changelog/krb5/?cs=24603)
has been added to the MIT Kerberos code to allow an application
to indicate that it wants to limit the encryption types negotiated.
(This functionality has been available on the client/initiator
side for a while. The new patch adds this support to the
server/acceptor side.)
This patch adds support to read a recently added nfsd
proc file to determine the encryption types supported by
the kernel and calls the function to limit encryption
types negotiated for the acceptor subkey.
Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com>