nfs-utils.git/utils/idmapd, branch gss-fixes

nfs-utils: consolidate mydaemon() and release_parent() implementations

2013-11-20T20:04:47+00:00

We currently have 2 cut-and-paste versions of this code. One for idmapd
and one for svcgssd.[1]

The two are basically equivalent but there are some small differences,
mostly related to how errors in that function are logged. svcgssd uses
printerr() with a priority of 1, which only prints errors if -v was
specified. That doesn't seem to be quite right. Daemonizing errors are
necessarily fatal and should be logged as such. The one for idmapd uses
err(), which always prints to stderr even though we have the xlog
facility set up. Since both have xlog configured at this point, log the
errors using xlog_err() instead.

The only other significant difference I see is that the idmapd version
will open "/" if it's unable to open "/dev/null". I believe that however
was a holdover from an earlier version of that function that did not
error out when we were unable to open a file descriptor. Since the
function does that now, I don't believe we need that fallback anymore.

[1]: technically, we have a third in statd too, but it's different
     enough that I don't want to touch it here.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve Dickson

rpc.idmapd: silence pointless EOF warning

2013-08-19T17:04:51+00:00

RH bz 831455 has a report that repeatedly mounting and unmounting over
lo can hit this warning in the EOF case.  I suspect that's just
normal--I'm not sure of the details, but probably idmapd gets woken up
to check for an upcall and then the upcall gets yanked away before
idmapd gets a chance to read it.

So just skip the warning in that case.  I also can't see a reason to
reopen.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Steve Dickson

rpc.idmapd: Ignore open failures in dirscancb()

2013-01-16T20:33:17+00:00

From: David Jeffery 

The daemon "rpc.idmapd" scans the /var/lib/nfs/rpc_pipefs/nfs/ directory
periodically looking for NFS client mounts to communicate to. The daemon
tried to open communication with a client mount but it disappeared in
between looking for directory entries and opening them. NFS mount was
umounted just before rpc.idmapd tried to communicate with it. This
behavior is usually seen when autofs is configured on the system.

Signed-off-by: Steve Dickson

idmapd: allow non-ASCII characters (UTF-8) in NFSv4 domain name

2012-12-17T21:33:17+00:00

The validateascii() check in imconv() maps NFSv4 domain names with
non-ASCII characters to 'nobody'. In setups where Active directory
or LDAP is used this causes names with UTF-8 characters to being
mapped to 'nobody' because of this check.

As Bruce Fields puts it:

"idmapd doesn't seem like the right place to enforce restrictions on
names.  Once the system has allowed a name it's too late to be
complaining about it here."

Replace the validateascii() call in imconv() with a check for
null-termination just to be extra-careful and remove the validateascii()
function itself as the only user of that function is being
removed by this patch.

Acked-by: J. Bruce Fields 
Signed-off-by: Suresh Jayaraman 
Signed-off-by: Steve Dickson

autoconf: don't let libnfsidmap test add -lnfsidmap to $LIBS

2012-01-05T20:42:40+00:00

...as that makes that library get linked into every binary. Also,
replace "hardcoded" -lnfsidmap linker flag in Makefiles with
a AC_SUBST variable.

This fixes a regression introduced in commit d7c64dd.

Signed-off-by: Jeff Layton

autoconf: fix up libevent autoconf test

2012-01-05T20:42:40+00:00

Have it set LIBEVENT to -levent and use that in the Makefiles instead
of hardcoding it.

Signed-off-by: Jeff Layton

rpc.idmapd: Dies with 'I/O possible'

2011-10-04T17:37:00+00:00

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 
Signed-off-by: Steve Dickson

idmapd: Fix decoding of octal encoded fields

2011-09-20T18:34:42+00:00

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 
Signed-off-by: Steve Dickson

nfs-utils: Move common code into support

2010-10-13T14:26:09+00:00

There are several source files and headers present in the ./utils/idmapd
directory which are also usable in a doimapd daemon. Because of this we
move that support into the support directory such that it can be shared by
both daemons.

Signed-off-by: Jim Rees 
Signed-off-by: Steve Dickson

rpc.idmapd: Type of idmap client should be defined by ic_id not ic_clid.

2010-09-16T11:13:43+00:00

The type of idmap_client is defined by idmap_client.ic_id for nfs,
so nfsd should have the same style.

Signed-off-by: Bian Naimeng 
Signed-off-by: Steve Dickson