| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Stumbled across this function, just had to simplify it. No mallocs
necessary, one quick loop to find the parameters. Much simpler.
Signed-off-by: David Hardeman <david@hardeman.nu>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
Make full use of inotify by not rescanning the whole tree on each change,
instead keep track of the inotify events and make sure that the minimum
work (scan/create/delete) clients is done in most cases. Still detect
anomalies and perform a full rescan in those cases.
Signed-off-by: David Hardeman <david@hardeman.nu>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
Using more relative paths saves memory and lets us get rid of more
PATH_MAX fixed arrays.
Signed-off-by: David Hardeman <david@hardeman.nu>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
Move all rpc_pipefs scanning code from gssd_proc.c to gssd.c in
preparation for later patches.
Signed-off-by: David Hardeman <david@hardeman.nu>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
| |
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using rpc.gssd to secure NFSv3 FS using krb5, the following errors
can happen as a result of network congestion.
"rpc.gssd WARNING: can't create tcp rpc_clnt to server ... : RPC: Remote
system error - Connection timed out"
we had a successful reproducer of the problem which we tested using this
patch by starting rpc.gssd with "-T 60" as the option which solved the
problem. reproducer steps were to throttle the network using tc command
and then in a never ending loop mount the share, then write some data in
the file on the share and unmount it. keep a delay of 5 sec between the
iteration of each loop.
CC: Christian Horn <chorn@redhat.com>
Signed-off-by: Rinku Kothiya <rkothiya@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
| |
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
In commit 51fda07a "gssd: scrape the acceptor name out of the context"
the allocated buffer size is not large enough to hold the actual data
that is written to the buffer. This fixes the allocated buffer size.
Reviewed-by: Jeff Layton <jlayton@poochiereds.net>
Signed-off-by: Veli-Matti Lintu <veli-matti.lintu@opinsys.fi>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
...and pass it to the kernel in the downcall. Legacy kernels will just
ignore the extra data, but with a proposed kernel patch the kernel will
grab this info and use it to verify requests on the v4.0 callback
channel.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
Contrary to the comment here, the lifetime_rec is not necessarily set
to zero on failure. That's only guaranteed to be the case if the context
has expired.
Cc: Andy Adamson <androsadamson@gmail.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
| |
...since its return code is ignored anyway.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
| |
...and get rid of some pointless NULL ptr checks.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
The name variable is always set to NULL now in all callers, so just
sto passing it around needlessly.
The uid_t variable is not used at all, so chuck it out too.
Signed-off-by: Simo Sorce <simo@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because gssd uses dnotify under the hood, it's easily possible that the
parent process can catch a signal while processing an upcall. If that
happens, then we'll currently exit the wait for the child task to exit,
and it'll end up as a zombie.
Fix this by ensuring that we only wait for the child to actually exit.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gssd doesn't properly clean up internal state for old pipes and never
closes the (since deleted) clnt_info directory. This leads to eventual
fd exhaustion.
To reproduce, run a lot of mount / umounts in a loop and watch the
output of 'ls /proc/$PID/fdinfo | wc -l' (where PID is the pid of gssd)
steadily grow until gssd eventually crashes with "Too many open files".
This regression was introduced by 841e83c1, which was trying to fix a
similar bug in the skip matching logic of update_old_clients. The
problem with that patch is that pdir will never match dirname,
because dirname is "<pname>/clntXXX".
Signed-off-by: Weston Andros Adamson <dros@netapp.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes gssd will open a new rpc-pipe but never read requests from it
or reply to them. This causes the kernel to wait forever for a reply.
In particular, if a filesystem is mounted by IP, and the IP has no
hostname recorded in /etc/hosts or DNS, then gssd will not listen to
requests and the mount will hang indefinitely.
The comment in process_clnt_dir() for the "fail_keep_client:" branch
suggests that it is for the case where we couldn't open some
subdirectories. However it is currently also taken if reverse DNS
lookup fails (as well as some other lookup failures). Those failures
should not be treated the same as failure-to-open directories.
So this patch causes a failure from read_service_info() to *not* be
reported by process_clnt_dir_files. This ensures that
insert_clnt_poll()
will be called and requests will be handled.
In handle_gssd_upcall, the current error path (taken when the mech is
not "krb5") does not reply to the upcall. This is wrong. A reply is
always appropriate. The only replies which aren't treated as
transient errors are EACCES and EKEYEXPIRED, so we return the former.
If read_service_info() fails then ->servicename will be NULL which will
cause process_krb5_upcall() (quite reasonably) to become confused. So
in that case we don't even try to process the up-call but just reply
with EACCES.
As clp->servicename==NULL is no longer treated as fatal, it is not
appropraite to use it to test if read_service_info() has been already
called on a client. Instread test clp->prog.
Finally, the error path of read_service_info() will close 'fd' if it
isn't -1, so when we close it, we should set fd to -1.
Acked-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The part of process_krb5_upcall that handles non-machine user creds
first tries to query GSSAPI for credentials. If that fails, it then
falls back to trawling through likely credcache locations to find them
and then points $KRB5CCNAME at it before proceeding. There are a number
of bugs in this code that this patch attempts to address.
The code that queries GSSAPI for credentials does it as root which
almost universally fails to do anything useful unless we happen to be
looking for non-machine root creds. Because of this, gssd almost always
falls back to having to search for credcaches "manually". The code that
handles credential switching is in create_auth_rpc_client, so it's too
late to be of any use here.
Worse yet, for historical reasons the MIT krb5 authors used %{uid} in
the default credcache locations which translates to the real uid. Thus
switching the fsuid or even euid is insufficient. You must switch the
real uid in order to be able to find the proper credcache in most cases.
This patch moves the credential switching to occur much earlier in the
process and has it do a much more thorough job of it. It first drops all
supplimentary groups, then determines a gid to use and switches the gids
and uids to the correct ones. If it can't determine the correct gid to
use, it then tries to look up the one for "nobody" and uses that.
Once the credentials are switched, the forked child now no longer tries
to change them back. It does the downcall with the new credentials and
just exits when it's done.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most krb5 installations use credcache locations that contain %{uid},
which expands to the real UID of the current process. In order for
GSSAPI to find those properly, we need to be able to switch the real UID
of the process to the designated one. That however, opens the door to
allowing gssd to be killed or reniced during the window where we've
switched credentials.
To combat this, change gssd to fork before trying to handle each upcall.
The child will do the work to establish the context and the parent task
will just wait for it to exit. It's still possible for the child to be
killed or reniced, but that would only affect a single upcall instead of
the entire daemon. Also, If the process is killed prematurely, then log
an error to tip off the admin that there was a problem.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: "J. Bruce Fields" <bfields@redhat.com>
The tgtname is of the form service@hostname. It's not a hostname, and
attempting to look it up here just causes failure of any upcall with a
"target=" field (currently, any upcall on behalf of an nfsv4.0
callback).
I think the theory was that knowning that target= name might help pick
the right keytab, but I don't really know if that's helpful. For now,
just stop trying to do this.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: "J. Bruce Fields" <bfields@redhat.com>
The tgtname is of the form service@hostname. It's not a hostname, and
attempting to look it up here just causes failure of any upcall with a
"target=" field (currently, any upcall on behalf of an nfsv4.0
callback).
I think the theory was that knowning that target= name might help pick
the right keytab, but I don't really know if that's helpful. For now,
just stop trying to do this.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: "J. Bruce Fields" <bfields@redhat.com>
Both dirname and pdir are null-terminated strings, so there's no reason
I can see for the strncmp.
And this gives the wrong result when comparing the "nfsd" and "nfsd4_cb"
directories! The results were callback clients being removed
immediately after creation, when lack of a client with the corresponding
name under "nfsd" lead gssd to believe it had disappeared from
"nfsd4_cb".
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible for a race to cause a name to appear when an rpc_pipefs
dir is scanned but to no longer be present when we try to open it.
So if the error is ENOENT, don't complain.
This is similar to
commit 5ac9bcfd820f09af4d3f87f1f7346d896f70bc9a
Author: David Jeffery <djeffery@redhat.com>
Date: Wed Jan 16 15:21:55 2013 -0500
rpc.idmapd: Ignore open failures in dirscancb()
which addressed a similar issue in idmapd.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The final version for this fix that was committed inverted the test
so makes no change in the important cases.
The documentation didn't really help a naive user know when the new -D
flag should be used.
And the code (once fixed) avoided DNS resolution on non-qualified names too,
which probably isn't a good idea.
This patch fixes all three issues.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
| |
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A NFS client should be able to work properly even if the DNS Reverse
record for the server is not set. This means a DNS lookup should not be
done on server names at are passed to GSSAPI. This patch changes the default
behavior to no longer do those types of lookups
This change default behavior could negatively impact some current
environments, so the -D option is also being added that will re-enable
the DNS reverse looks on server names, which are passed to GSSAPI.
Signed-off-by: Simo Sorce <simo@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GSSAPI can be given a uid number as a special name, and then
gss_acquire_cred() can use the name to try to find credentials for
the user.
Give GSSAPI a chance to do it on its own, then fallback to the classic
method of trolling through the file system to find a credential cache.
This patch uses a little know feature of GSSAPI that permits to acquire
crdentials specifying the user's UID. Normally GSSAPI will simply
perform a getpwuid() call and use the user name to generate a principal name and
then see if it can find a TGT for that principal in the local ccache.
This feature is vital to allow the GSS-Proxy to be able to initiate
crdentials on behalf of rpc.gssd using client keytabs stored in the filsystem.
GSS-Proxy works through an interposer-type plugin (new feature in MIT 1.11)
that allows to intercept all GSSAPI requestes and relay them to a system
daemon via a socket. This daemon (GSS-Proxy) then can perform operations
on behalf of other applications with additional logic.
In the rpc.gssd case the GSS-Proxy daemon allows applications running as
system users to properly access krb5 protected shares by creating a
credential cache on the fly when necessary.
This way all applications that need access to krb5 protected shares do not need
to be taught how to initiate crdentials on their own, nor they need to be
wrapped in additional init scripts like k5start or use wasteful cronjobs to
keep credentials fresh. All is needed is to drop a keytab with the right keys
in a special location on the system and gss-proxy will do the rest.
Signed-off-by: Simo Sorce <simo@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using GSSAPI's gss_krb5_export_lucid_context the context passed
into the function is actually deleted during the export (to avoid
reuse as the context contains state that depends on its usage).
Change the code to pass in a pointer to the context so that it can be
properly NULLed if we are using the GSSAPI context and following calls to
gss_delete_sec_context will not cause double free errors and segfaults.
Signed-off-by: Simo Sorce <simo@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
| |
Acked-by: J. Bruce Fields <bfields@fieldses.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 7c5cb5e732a4b8704f8c79ec819c5d271e040339
gssd: base the size of the fd array on the RLIMIT_NOFILE limit.
didn't actually work as claimed. It only uses the returned value
if getrlimit() returns -1 -- which of course it only does when
there was an error.
So change the test to "== 0".
Reported-by: Leonardo Chiquitto< lchiquitto@suse.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
librpcsecgss provides authgss_free_private_data() as a pair to
authgss_get_private_data(). libtirpc does not - until recently.
This ommision results in authgss_destroy_context() sending an
incorrect RPCSEC_GSS_DESTROY request when gssd calls AUTH_DESTROY().
The call has been added to libtirpc, so this patch updates nfs-utils
to check for the presense of the function in libtirpc and to set
HAVE_AUTHGSS_FREE_PRIVATE_DATA if it is present.
This is also set unconditionally if librpcsecgss is used.
gssd is changed to test this value rather than HAVE_LIBTIRPC when
chosing whether to call authgss_free_private_data().
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
We have previously raised the size of the 'pollarray' once (32 -> 256)
and I have had another request to make it bigger.
Rather than changing the hard-coded value, make it depend on
RLIMIT_NOFILE. This is an upper limit on the size of the array
that can be passed to poll() anyway.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
I can see no possible point for this test against FD_ALLOC_BLOCK,
so just remove the test.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
get_poll_index wants to walk the entire "pollarray", but uses
the constant FD_ALLOC_BLOCK, rather than the variable
pollsize (which has the same value). If we want to make the
size of the array variable, it is best not to use the constant.
As pollsize is 'unsigned long', 'i' should be too.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The target name contains a hostname in the realm that we are
authenticating
to. Since we may be authenticating to a different realm than the default
realm for the server, we should not assume that the target name and host
name point to the same string.
In fact, the kernel NFS client will always use its own hostname as the
target name, since it is always authenticating to its own default realm.
On the other hand, the NFS server's callback channel will pass the
hostname
of the NFS client that it is authenticating too (Section 3.4, RFC3530).
This patch fixes the handling of the target name in process_krb5_upcall,
and ensures that it gets passed to find_keytab_entry().
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Either we trust the info file, or we don't. The current
'checks' only work for the combination 'nfs', '100003' and
a version number between 2 and 4.
The problem is that the callback channel also wants to use
'nfs' in combination with a different program number and
version number.
This patch throws the bogus checks out altogether and lets the
kernel use whatever combination it wants....
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
gssd_proc.c: In function handle_krb5_upcall:
gssd_proc.c:1117:2: warning: ISO C forbids return with expression, in
function returning void [-pedantic]
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
gssd_proc.c: At top level:
gssd_proc.c:782:5: warning: no previous prototype for create_auth_rpc_client [-Wmissing-prototypes]
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: Andy Adamson <andros@netapp.com>
The kernel gss_cl_ctx stores the context lifetime in gc_expiry, set
by gssd in do_downcall() called by process_krb5_upcall(). The lifetime
value is currently not related at all to the Kerberos TGS lifetime.
It is either set to the value of gssd -t <timeout>, or to a kernel
default of 3600 seconds.
Most of the time the gssd -t command line is not set, and a timeout
value of zero was sent to the kernel triggering the use of the 3600
second kernel default timeout.
In order for the kernel to properly know when to renew a context, or to
stop buffering writes for a context about to expire, the gc_expiry value
needs to reflect the credential lifetime used to create the context.
Note that gss_inquire_cred returns the number of seconds for which the
context remains valid in the lifetime_rec parameter.
Send the actual TGS remaining lifetime to the kernel. It can still be
overwritten by the gssd -t command line option, or set to the kernel
default if the gss_inquire_cred call fails (which sets the lifetime_rec
to zero).
Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
Newer versions of systemd create a /run/user/${UID} directory
instead of the /run/user/${USER} directory, so switch to
scanning for that. To make the per-user directory bit a little
less magical, change the default to incorporate a "%U", which
gets dynamically expanded to the user's UID when needed.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use ppoll() instead.
[ cel Wed Aug 1 11:44:46 EDT 2012 - autoconfiscated Bruce's version ]
Related clean-up: Since we're pulling the poll/ppoll call out into a
separate function, note that the second argument of poll(2) and
ppoll(2) is not an int, it's an unsigned long. The nfds_t typedef
is a recent invention, so use the raw type for compatibility with
older glibc headers.
Acked-by: J. Bruce Fields" <bfields@redhat.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a POLLHUP event is received on a pipe file descriptor, that
means the other side has closed its end of the pipe. If the
receiver does not close its end of the pipe, the pipe is left in an
open-but-unlinked state.
For a "gssd" upcall pipe, the kernel may close its end, removing the
directory entry for it, and then later create a fresh pipe named
"gssd" in the same directory. In this case, rpc.gssd continues to
listen on the open-but-unlinked previous "gssd" pipe. Thus upcalls
on the new "gssd" pipe are left unanswered.
In addition, poll(2) continues to return POLLHUP on the old pipe.
Since there is no logic to close the pipe in rpc.gssd, poll(2) always
returns immediately, and rpc.gssd goes into a tight loop.
Typically, the kernel closes upcall pipes and destroys their
parent directory at the same time. When an RPC client's directory
vanishes, rpc.gssd sees the change via dnotify and eventually
invokes destroy_client() which closes the user-space end of the
pipes.
However, if the kernel wants to switch authentication flavors (say
from AUTH_KRB5 to AUTH_UNIX) on an RPC client without destroying it,
the upcall pipes go away, but the RPC client's directory remains.
rpc.gssd invokes update_client_list(), but that logic never closes
upcall pipes if the client directory is still in place.
After a POLLHUP on a pipe, close it when rpc.gssd reconstructs its
list of upcall clients.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
The user credential cache currently is kept in /tmp.
In upcoming Kerberos release that will be moved to
/run/user/<username>/. This patch enables gssd to
look in both the old and new caches
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
| |
Signed-off-by: Simo Sorce <simo@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
Modify wrong err message at handle_gssd_upcall when
sscanf encryption types fail.
Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
gssd_proc.c: In function 'create_auth_rpc_client':
gssd_proc.c:939: warning: comparison between signed and unsigned integer expressions
gssd_proc.c:939: warning: comparison between signed and unsigned integer expressions
gssd_proc.c: In function 'handle_krb5_upcall':
gssd_proc.c:1164: warning: comparison between signed and unsigned integer expressions
gssd_proc.c: In function 'handle_spkm3_upcall':
gssd_proc.c:1178: warning: comparison between signed and unsigned integer expressions
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
krb5_util.c: In function 'realm_and_service_match':
krb5_util.c:617: warning: unused parameter 'context'
krb5_util.c: In function 'limit_krb5_enctypes':
krb5_util.c:1275: warning: unused parameter 'uid'
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
| |
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
This patch replaces a hard-coded list with a function to obtain
the Kerberos encryption types that the kernel's rpcsec_gss code
can support. Defaults to old behavior if kernel does not supply
information.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently if a krb5 context expires, GSSAPI authenticated RPC calls
start returning error (-EACCES in particular). This is bad when someone
has a long running job that's doing filesystem ops on a krb5 authenticated
NFS mount and just happens to forget to redo a 'kinit' in time.
The existing gssd always does a downcall with a '-1' error code if there
are problems, and the kernel always ignores this error code. Begin to
fix this by having gssd distinguish between someone that has no
credcache at all, and someone who has an expired one. In the case where
there is an existing credcache, have gssd downcall with an error code of
-EKEYEXPIRED. If there's not a credcache, then downcall with an error of
-EACCES.
We can then have the kernel use this error code to handle these
situations differently.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent kernels (2.6.32) have started displaying the scopeid for some
addresses in the upcall. gssd doesn't know how to deal with them. Change
gssd to use getaddrinfo instead of inet_pton since that can deal with
scopeid's in addresses. That also allows us to elminate the port
conversion in read_service_info.
If getaddrinfo returns an address with a non-zero sin6_scope_id however,
reject it. getnameinfo ignores that field and just uses the sin6_addr
part when resolving. But, two addresses that differ only in
sin6_scope_id could refer to completely different hosts.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|