[Bug 1918312] Re: group changes don't show up in kerberizedd mounts

[Steve Beattie]

Hey Charles,

Apologies for the lack of response earlier. I see that you have gone ahead and reported this issue to upstream at 
https://lore.kernel.org/linux-nfs/CC0F1034-8572-4556-8351-28499903258C@rutgers.edu/

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

https://lore.kernel.org/linux-
nfs/20120117162820.GA13977 at fieldses.org/T/#u

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

** Information type changed from Private Security to Public Security

** Changed in: nfs-utils (Ubuntu)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1918312

Title:
  group changes don't show up in kerberizedd mounts

Status in nfs-utils package in Ubuntu:
  Confirmed

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1918312/+subscriptions