NFSv4 and root access

Matt Garman matthew.garman at gmail.com
Tue Jun 3 11:08:29 EDT 2014


On Tue, Jun 3, 2014 at 9:23 AM, Jaap <jwinius at umrk.nl> wrote:
> On Fri, 30 May 2014 10:57:45 -0500, Matt Garman wrote:
>
>> ... Then under the [Static] section of idmapd.conf
>> (on the nfsv4 server), I have:
>> matt/cron at REALM = matt
>
> For my site, this would mean that the idmapd.conf on every workstation
> would have to include an alternate entry for every possible user, so it's
> not a practical solution. Nevertheless, it was an interesting post.

I don't believe that's the case.  I'm assuming every workstation is
only an NFS client, and therefore, does not even need to run idmapd.
At least in my setup, on my nfs client machines (which is several
dozen), I haven't even touched the /etc/idmapd.conf file.

I have only modified the /etc/idmapd.conf files on my nfsv4 servers
(which is two [three if you count a hot-backup server]).

So if I understand your problem correctly, then you should only have
to manage the super-set of alternate users in one idmapd.conf file (or
at least only as many nfs servers as you run).

That still could be messy if you have a lot of users.  Theoretically
it's a one-time big pain, and, unless you have a lot of user turnover,
relatively minor/short-lived pain afterwards.

Going back to your original comment:

> the workstations have an elaborate logout
> script in /etc/X11/Xreset.d/ that runs as root (it contains many sudo
> commands to modify to the user's home directories). A solution might be
> to avoid running the logout script as root, but AFAIK that's not possible.

Another thought is that you don't have to have an alternate user for
each and every user.  Just define a global "sudo user", and let
everyone map to that... having typed that, it feels a little sketchy,
so there might be some security implications I'm overlooking.

Does idmapd.conf allow similar mapping for groups?  I assume that's
how your sudo config is setup, everyone belongs to a common group
which gives them the particular access to run the necessary sudo
commands.  Otherwise, you'd be maintaining massive, ugly /etc/sudoers
files on all workstations.  So if you can achieve the idmapd.conf
functionality I suggested at the group level, that might be all you
need to do.

Hope that helps or at least gives you some ideas.


More information about the Kerberos mailing list