group changes don't show up in kerberizedd mounts

[Charles Hedrick]

The problem described in https://linux-nfs.vger.kernel.narkive.com/dgTL2KiI/svcgssd-allow-administrators-to-specify-timeout-for-the-cached-context is still present. The patch described there needs to be applied.

TO reproduce:

On file system mounted sec=krb5, login as user xxx. Cd to user yyy's directory.
Add user's xxx and yyy to group ggg.
As user yyy, create directory ddd, chgrp ggg ddd
As user xxx, try to view ddd. This will fail.

THe problem is that the nfs context for xxx was established when they accessed the file system. When they were added to the group, the context didn't have it. In theory the context will be refeshed when the Kerberos ticket expires. 1) that's typically a day, which is too long a delay 2) it doesn't actually happen.

The patch allows you to tell the server to expire contexts after some finite period. We're using 30 minutes. I'm also using a slightly different version of the patch.

Instead of just ctx_endtime = now + 1800 (I've hardcoded the time to minimize the patch) I'm using

+ /* timeout in 30 min or ticket expiration, whichever is sooner */
+ {// so we can use a local variable //
+ time_t now = time(0);
+
+ if ((now + 1800) < ctx_endtime) {
+ ctx_endtime = now + 1800;
+ }
+
+ }
+

This is technially a security problem. If a user wants to remove access from someone, it can take an arbitrarily long period to take effect. The original bug noted this as a security problem, and others involve din the discussiosn agreed.

I have no idea why this patch never got appied upstream.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: nfs-common 1:1.3.4-2.5ubuntu3.3 [modified: usr/sbin/rpc.svcgssd]
ProcVersionSignature: Ubuntu 5.4.0-65.73-generic 5.4.78
Uname: Linux 5.4.0-65-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
CasperMD5CheckResult: skip
Date: Tue Mar 9 12:34:03 2021
InstallationDate: Installed on 2020-03-25 (348 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
ProcEnviron:
 TERM=vt100
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/tcsh
SourcePackage: nfs-utils
UpgradeStatus: Upgraded to focal on 2020-12-21 (77 days ago)
modified.conffile..etc.default.apport: [modified]
mtime.conffile..etc.default.apport: 2020-08-10T17:26:17.512725
mtime.conffile..etc.default.nfs-common: 2020-04-16T16:03:31.356462

[Charles Hedrick (hedrick)]

On our systems, user credentials are automatically renewed about halfway through their lifetime, as long as the user is still logged in. I wonder if this means that the expiration at the end of the ticket lifetime never triggers, so the fix in eb3a145789b9eedd39b56e1d76f412435abaa747 doesn't actually do anything.

I added myself to a group, logged out and logged in (so I'd show up in the group on the client), cd'd to the file system, but was never able to see a file owned by another user protected by that group. Even after a weekend, which is well beyond how long the original ticket lifetime.

[Steve Beattie (sbeattie)]

Hey Charles,

Apologies for the lack of response earlier. I see that you have gone ahead and reported this issue to upstream at
https://<email address hidden>/

This response explains why things take a long time or don't show up at all:

https://<email address hidden>/T/#u

(link also includes more of the discussion about the issue.)

[Steve Beattie (sbeattie)]

(Bah, didn't realize the original link contained the full thread as well.)

[Charles Hedrick (hedrick)]

I'm well aware of the problem. I see lots of reports that produce discussions that wander off with nothing done, even though there's an actual fix in the thread. I run a moderately large site that uses Kerberos extensively, and kerberoized NFS. I have a whole github repository full of workarounds for problems I can't get fixed. Perhaps this one could be different.

https://github.com/clhedrick/kerberos

[Charles Hedrick (hedrick)]

Id be happy to help make changes to the relevant tools so I don't need the hacks in that repository if any maintainers would be interested.