[ClusterLabs Developers] RFC: "chown" option for the Filesystem resource agent
Ken Gaillot
kgaillot at redhat.com
Fri Jan 14 15:04:44 UTC 2022
On Fri, 2022-01-14 at 15:10 +0100, Christoph Böhmwalder wrote:
> Hi all,
>
> we have a use case where we automatically set up an NFS export,
> including a corresponding Filesystem primitive. The file system is
> replicated via DRBD, and we have another tool which makes the `mkfs`
> call when creating the DRBD resource. Since this export is only used
> for
> anonymous access, we are using the "all_squash" option on the NFS
> server.
>
> The problem we are now facing is that the top level directory of the
> newly created filesystem will be owned by "root", but we need it to
> be
> owned by "nobody" so that the anonymous access via "all_squash"
> works.
>
> We were wondering if there is interest in (or at least no strong
> opposition to) an option on the Filesystem resource agent which does
> exactly that: chown the top level directory to "nobody" iff it is
> empty
> and owned by root. So basically, something like setting the "initial
> owner" of the file system.
>
>
> (Side note: your impulsive reaction may be to tell us to just do the
> chown wherever we create the file system, so let me explain our
> reasoning why we want to avoid that. This "other tool" is
> LINSTOR[0],
> which is – for the sake of this argument – essentially a
> configuration
> generator/manager for DRBD resources. The fact that we create the
> file
> system there is already kind of a hack. We justified it by thinking
> of
> the "mkfs" as part of the process of creating a DRBD resource.
> Mounting
> the file system, chowning the TLD and unmounting it again would be
> even
> worse, and hardly fits the definition of "creating a resource"
> anymore.
Actually I don't see a problem doing it there. mount-chown-unmount is
not much extra overhead compared to mkfs, and is logically more related
to creation than repeated use. Also there are numerous other such
initializations that could be desired, like permissions, SELinux
labels, access control lists, tuning parameters,...
> So, in short, we think it would be less complex to do this within
> the
> Filesystem resource agent, where the file system is already being
> mounted.)
>
>
> I agree that this may seem too specific of a use case, but we think
> that
> such an option could be a benefit in some cases. Maybe there is even
> an
> application beyond all_squash NFS exports that we are not thinking
> of.
>
> Lars Ellenberg kindly volunteered to implement such an option if
> there
> is no disapproval.
>
> Anyways, I'm looking forward to hearing your opinion on this.
>
> [0] https://github.com/LINBIT/linstor-server
>
--
Ken Gaillot <kgaillot at redhat.com>
More information about the Developers
mailing list