That idea seems similar to the suggestion by Russ back in 2002 on running Apache
https://lists.openafs.org/pipermail/openafs-info/2002-May/004440.html I guess the idea is to bind the machine (or the AFS directory) to a dedicated Kerberos principal. I guess I can create a Kerberos principal and create the corresponding pts entry, export the keytab to a file and store it in those machines' local directory, one which can only be accessed by root. Then somehow modify the service launch script to use Russ's k5start<https://www.eyrie.org/~eagle/software/kstart/k5start.html> to obtain a token and start the daemon binary in the protected AFS directory. That way the wire privacy is maintained by the encryption. The potential risk is that if a unauthorized user gains root on the machine, he/she may be able to access the AFS directory. But that is no worse than an IP-based method where every user of that machine will be able to get access to that directory. It seems doable, except that I am not the admin of our Kerberos domain… But I can figure that out. Thanks! Best regards, Simon -----Original Message----- From: Garance A Drosehn [mailto:[email protected]] Sent: Friday, January 26, 2018 1:46 PM To: Ximeng Guan <[email protected]> Cc: [email protected] Subject: Re: [OpenAFS] Is member of a machine group honored as system:authuser? 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/[email protected]', 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 = [email protected]<mailto:[email protected]> Senior Systems Programmer or [email protected]<mailto:[email protected]> Rensselaer Polytechnic Institute; Troy, NY; USA
