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]
Senior Systems Programmer or [email protected]
Rensselaer Polytechnic Institute; Troy, NY; USA
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
