Hi Ben, Garance and Jeffrey, Thank you all for the clarification and advice.
For now I will follow Garance's suggestion to create a common machine group and use it to open up the path from /afs down to the point where a specific machine group is needed, and then use the specific machine group from there. Thanks to Jeffrey for pointing out the potential risks of using machine based ACL (data integrity and wire privacy unprotected) in OpenAFS. It is great to learn that Auristor has developed and commercialized a solution to this, which a startup like us can later on turn to for support when we grow. I realize that my need for a machine-based access actually has two folds: On the one hand we want to protect the software installation path so that it can be accessed by users of machines from a certain office or geographic location. On the other hand we want those particular machines to gain access to the installation path at boot without any human interference. 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. By the way can someone kindly reply this message so that it does not appear to be encrypted in the archive? Somehow I found my original message to show up as encrypted in the archive. Thanks. Ximeng (Simon) -----Original Message----- From: Benjamin Kaduk [mailto:[email protected]] Sent: Wednesday, January 24, 2018 8:14 PM To: Ximeng Guan <[email protected]> Cc: [email protected] Subject: Re: [OpenAFS] Is member of a machine group honored as system:authuser? On Wed, Jan 24, 2018 at 07:31:51PM +0000, Ximeng Guan wrote: [snip] > Did I miss anything here? I don't think so. It's probably best to think of system:authuser as a shorthand for "all entities that can authenticate to the protection server", users and keytab-based credentials. The machine/IP prdb entries are in an intermediate space, in which they can appear on access control lists but nothing can actually authenticate directly as those pts entries. It seems like a weird design choice now, but probably made sense a the time. pts_createuser(1) has some information about the actual functionality. Garance's suggestion of (essentially) adding an additional layer of abstraction seems to be the best practice for this area. -Ben
