| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: Harald Hoyer <harald@redhat.com>
PR_CAPBSET_DROP can return EINVAL, if an older kernel does support
some capabilities, which are defined by CAP_LAST_CAP, which results in
a failure of the service.
For example kernel 3.4 errors on CAP_EPOLLWAKEUP, which was newly
introduced in 3.5.
So, for future capabilities, we clear until we get an EINVAL for
PR_CAPBSET_READ.
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
statd drops all capabilities except for CAP_NET_BIND when it starts.
It's possible though that if it ever had a compromise that an attacker would
be able to invoke a setuid process (or something with file capabilities) in
order to reinstate some caps.
This could happen as a result of the daemon becoming compromised, or
possibly as a result of the ha-callout program becoming compromised.
In order to prevent that, have statd also prune the capability bounding
set to nothing prior to dropping capabilities. That ensures that the
process won't be able to reacquire capabilities via any means --
including exec'ing a setuid program.
We do however need to be cognizant of the fact that PR_CAPBSET_DROP was
only added in 2.6.25, so check to make sure that #define exists via
autoconf before we rely on it. In order to do that, we must add
ax_check_define.m4 from the GNU autoconf macro archive.
Furthermore, do a runtime check to see if /proc/sys/kernel/cap-bound
exists before attempting to clear the bounding set. If it does, then
don't bother trying since it won't work. In that event though, do
throw a warning however since the presence of that file indicates that
there is a disconnect between the build and runtime environments.
Acked-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
At nsm_drop_privileges(), for improving readability, unify
the return value.
Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Monitored host information is stored in files under /var/lib/nfs.
When visiting entries in the monitored hosts directory, libnsm.a
examines the value of dirent.d_type to determine if an entry is a
regular file.
According to readdir(3), the d_type field is not supported by all
file system types. My root file system happens to be one where d_type
isn't supported. Typical installations that use an ext-derived root
file system are not exposed to this issue, but those who use xfs, for
instance, are.
On such file systems, not only are remote peers not notified of
reboots, but the NSM state number is never incremented. A statd warm
restart would not re-monitor any hosts that were monitored before
the restart.
When writing support/nsm/file.c, I copied the use of d_type from the
original statd code, so this has likely been an issue for some time.
Replace the use of d_type in support/nsm/file.c with a call to
lstat(2). It's extra code, but is guaranteed to work on all file
system types.
Note there is a usage of d_type in gssd. I'll let gssd and rpcpipefs
experts decide whether that's worth changing.
Fix for:
https://bugzilla.linux-nfs.org/show_bug.cgi?id=193
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the __attribute_noinline__ form with
__attribute__((__noinline__)).
Even though the compiler didn't complain about __attribute_malloc__,
also replace those in order to maintain consistent style throughout the
source file.
Fix for:
https://bugzilla.linux-nfs.org/show_bug.cgi?id=194
Reported-by: "Gabor Z. Papp" <gzp@papp.hu>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
The new code using libcap is quite minor, so rather than always reqiure
libcap support, make it a normal --enable type flag. Current default
behavior is retained -- if libcap is found, it is enabled, else it is
disabled like every nfs-utils version in the past.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm about to switch the order of listener creation and dropping root
privileges. rpc.statd will drop privileges first, then create its
listeners. The reason for the new ordering is explained in a
subsequent patch.
However, for non-TI-RPC builds, rpc_init() needs to use a privileged
port to do pmap registrations. For both TI-RPC and non-TI-RPC builds,
CAP_NET_BIND is required in case the admin requests a privileged
listener port on the statd command line.
So that these requirements are met, nsm_drop_privileges() will now
retain CAP_NET_BIND while dropping root.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support IPv6, statd must support multi-homed remote peers. For our
purposes, "multi-homed peer" means that more than one unique IP
address maps to the one canonical host name for that peer.
An SM_MON request from the local lockd has a "mon_name" argument that
statd reverse maps to a canonical hostname (ie the A record for that
host). statd assumes the canonical hostname is unique enough that
it stores the callback data for this mon_name in a file named after
that canonical hostname.
Because lockd can't distinguish between two unique IP addresses that
may be from the same physical host, the kernel can hand statd a
mon_name that maps to the same canonical hostname as some previous
mon_name. So that the kernel can keep this instance of the mon_name
unique, it creates a fresh priv cookie for each new address.
Note that a mon_name can be a presentation address string, or the
caller_name string sent in each NLMPROC_LOCK request. There's
nothing that requires the caller_name to be a fully-qualified
hostname, thus it's uniqueness is not guaranteed. The current
design of statd assumes that canonical hostnames will be unique
enough.
When a mon_name for a fresh SM_MON request maps to the same canonical
hostname as an existing monitored peer, but the priv cookie is new,
statd will try to write the information for the fresh request into an
existing monitor record file, wiping out the contents of the file.
This is because the mon_name/cookie combination won't match any record
statd already has.
Currently, statd doesn't check if a record file already exists before
writing into it. statd's logic assumes that the svc routine has
already checked that no matching record exists in the in-core monitor
list. And, it doesn't use O_EXCL when opening the record file. Not
only is the old data in that file wiped out, but statd's in-core
monitor list will no longer match what's in the on-disk monitor list.
Note that IPv6 isn't needed to exercise multi-homed peer support.
Any IPv4 peer that has multiple addresses that map to its canonical
hostname will trigger this behavior. However, this scenario will
become quite common when all hosts on a network automatically get both
an IPv4 address and an IPv6 address.
I can think of a few ways to address this:
1. Replace the current on-disk format with a database that has a
uniqueness constraint on the monitor records
2. Create a new file naming scheme; eg. one that uses a truly
unique name such as a hash generated from the mon_name, my_name, and
priv cookie
3. Support multiple lines in each monitor record file
Since statd's on-disk format constitutes a formal API, options 1 and 2
are right out. This patch implements option 3. There are two parts:
adding a new line to an existing file; and deleting a line from a file
with more than one line. Interestingly, the existing code already
supports reading more than one line from these files, so we don't need
to add extra code here to do that.
One file may contain a line for every unique mon_name / priv cookie
where the mon_name reverse maps to the same canonical hostname. We
use the atomic write facility added by a previous patch to ensure the
on-disk monitor record list is updated atomically.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We're about to use the same logic (mktemp, write, rename) for
other new purposes, so pull it out into its own function.
This change also addresses a latent bug: O_TRUNC is now used when
creating the temporary file. This eliminates the possibility of
getting stale data in the temp file, if somehow a previous "atomic
write" was interrupted and didn't remove the temporary file.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To manage concurrency, both statd and sm-notify construct raw RPC
requests in socket buffers, and use a minimal request scheduler
to send these requests and manage replies. Both statd and sm-notify
open code the RPC request construction.
Introduce helper functions that can construct and send raw
NSMPROC_NOTIFY, NLM downcalls, and portmapper calls over a datagram
socket, and receive and parse their replies. Support for IPv6 and
RPCB_GETADDR is featured. This code (and the IPv6 support it
introduces) can now be shared by statd and sm-notify, eliminating
code and bug duplication.
This implementation is based on what's in utils/statd/rmtcall.c now,
but is wrapped up in a nice API and includes extra error checking.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
| |
|
|
|
| |
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rpc.statd and sm-notify access the same set of files under
/var/lib/nfs/statd, but both have their own code base to handle this.
They should share this code.
In addition, the on-disk format used by statd and friends is
considered a formal interface, so this new code will codify the API
and provide documentation for it.
The shared code handles switching from the default parent statd
directory, reducing privileges at start-up, and managing the NSM
state files, in addition to handling normal operations on the
monitored host and notification lists on disk.
The new code is simply a copy of the same logic that was used in
rpc.statd and sm-notify, but wrapped in a nice API. There should be
minimal behavioral and no on-disk format changes with the new
libnsm.a code.
The new code is more careful to check for bad corner cases.
Occassionally this code may not allow an operation that was permitted
in the past, but hopefully the error reporting has improved enough
that it should be easy to track down any problems.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
Clean up: Move the .x file and the generated C source for NSM to
libnsm.a, echoing the architecture of mountd and exportfs. This makes
the NSM protocol definitions, data types, and XDR routines available
to be shared across nfs-utils.
This simplifies the addition of other NSM-related code (for example
for testing or providing clustering support), and also provides
public data type definitions that can be used to make sense of the
contents of statd's on-disk database.
Because sim_sm_inter.x still resides in utils/statd, I've left some
rpcgen build magic in utils/statd/Makefile.am.
This is an internal organization change only. This patch should not
affect code behavior in any way.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
