[OpenAFS] Is member of a machine group honored as
Garance A Drosehn
Fri, 26 Jan 2018 16:45:45 -0500
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
> 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
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
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
Then to get rid of access you could do:
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@example.com
Senior Systems Programmer or gad@FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA