[OpenAFS] Is member of a machine group honored as system:authuser?

[Garance A Drosehn]

On 25 Jan 2018, at 17:50, Ximeng Guan wrote:
>
> The actual scenario is that there are daemon service binaries in that 
> installation path which we would like each machine of the group to 
> launch by its local root, every time the machine is rebooted (through 
> SysVinit script or systemd). You may think of those machines as the 
> workhorse part of a simulation program that listens on certain port 
> for job submissions by client users. The program is parallelized by 
> MPI and can potentially distribute a simulation job among those 
> machines.
>
> In other words while we do want to block machines out of the machine 
> group from accessing the AFS path, for those in the machine group we 
> would like them to gain access to the specific AFS path at boot, right 
> after the AFS service is up but preferably without the need of any 
> human user authentication.
>
> I think that's a more complete description of my usage scenario. I 
> hope this discussion helps others who may have similar need in the 
> future.

Hmm.  Well, there's another tactic which I use in a few situations.  I'm 
not sure if it would work for yours.

I create a host-specific key in our krb5 database.  I take that and put 
it in the appropriate file under /etc on the machine which needs access. 
  I then do a 'pts createuser rcmd.<host>', where <host> is the short 
hostname of the host in question.  So I might create a krb5 hostkey for 
'host/garance.test.rpi.edu@RPI.EDU', and add a PTS user for 
'rcmd.garance'.

Then if I am logged in as root on that machine, I can type:

kinit -k			# no password needed
aklog			# no password needed

And then 'root' will have access to things which have been permitted to 
rcmd.garance in our campus space.  This is different than machine-group 
tactic, because it is only userid root on that machine who will have 
access to the directories which have been permitted to rcmd.<host>.  
Other users on the same machine will not gain access.

But if your daemon service binaries are running as root, then maybe 
that'll work for you.  You'd also have to pay attention to 
token-expiration times, which you wouldn't have to do with 
machine-groups.

Then to get rid of access you could do:

unlog
kdestroy

But note that means that ALL root-owned processes will lose access.  So 
if you have multiple daemons using aklog, then unlogging from one of 
them will cause all of them to lose access.  So that's a significant 
concern when doing unlog/kdestroy.

Yet another tactic we do is to create some fake user in PTS, and stash 
away the password to it somewhere where it is "safe" (say, as a file 
inside of /etc/security).  We could then have some daemon process start 
up use that hidden password to authenticate to the fake user, and then 
that daemon will have access to the directories permitted to the fake 
user.  Once again you'd have to pay attention to token-expiration times 
(via one method or another).

All of these were initially used at RPI before I took over maintenance 
of the AFS cell at RPI, and I suspect that which method was used 
depended on who was setting up the daemon or other service.

-- 
Garance Alistair Drosehn                =     drosih@rpi.edu
Senior Systems Programmer               or   gad@FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA