> On Feb 16, 2022, at 3:44 PM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: > > On 16 Feb 2022, at 14:35, Chuck Lever III wrote: > >> On Feb 16, 2022, at 2:01 PM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: >>> Coming back to this.. so it seems at least part of our disagreement about >>> the name had to do with a misunderstanding of what the tool did. >> >> I understand what your implementation does. I don't >> understand why it works that way. >> >> The disagreement is that I feel like you're trying to >> abstract the operation of this little tool in ways that >> no-one asked for. It's purpose is very narrow and >> completely related to the NFSv4 client ID. >> >> >>> Just to finally clear the air about it: the tool does not write to sysfs, it >>> doesn't try to modify the client in any way. I'm going to leave it up to >>> the distros. >> >> Seems to me that the distros care only about where the >> persistence file is located. I can't see a problem with >> Neil's suggestion that the tool also write into sysfs. >> The location of the sysfs API is invariant; there should >> be no need to configure it or expose it. >> >> Can you give a reason why the tool should /not/ write >> into sysfs? > > So that there is a division of work. Systemd-udevd handles the event and > sets the attribute, not the tool. Systemd-udevd is already set up to have > the appropriate selinux contexts and rights to make these changes. > Systemd-udevd's logging can clearly show the action and result instead > of it being hidden away inside this tool. Systemd-udevd doesn't expect > programs to make the changes, its designed around the idea that programs > provide information and it makes the changes. > > You can see how many issues we got into by imagining what would happen if > users ran this tool. If the tool doesn't modify the client, that's one less > worry we have upstream, its the distro's problem. > > If the tool writes to sysfs, then someone executing it manually can change > the client's id with a live mount. That's bad. That's less likely to > happen if its all tucked away in a udev rule. I know the counter-arguement > "you can write to sysfs yourself", but I still think its better this way. > > There's increased flexibility and utility - if an expert sysadmin wants to > distinguish groups of clients, they can customize their udev rule to add > custom strings to the uniquifier using the many additional points of data > available in udev rules. I was not aware of the SELinux requirement and the particular interactions the tool would have with systemd. Thanks for explaining! I think a "set-like" tool would work fine. We have plenty of those. But I now understand why you designed the tool this way, so I don't mind either way. The tool's man page, if we proceed in that direction, should summarize the systemd expectations (along with a SEE ALSO citation). -- Chuck Lever
