Re: [PATCH V12 10/12] famfs: Add runtime operation-permission (opts) framework

On 26/08/05 10:31PM, Darrick J. Wong wrote:
> On Mon, Aug 03, 2026 at 02:29:57AM +0000, John Groves wrote:
> > From: John Groves <[email protected]>
> > 
> > famfs denies most namespace, attribute and data operations by default
> > because the userspace log, not the kernel, is authoritative for a famfs
> > instance. Earlier commits already guard each such operation with a
> > famfs_opt_enabled(fsi, FAMFS_OPT_x) check backed by a permissive stub. This
> > commit defines the permission bitmap and makes those checks live.
> 
> Why would it ever be acceptable for user programs to mess with the
> directory tree and file attributes?  There's nothing here that would
> seem to write to the userspace log.  Or am I mistaken, and only the
> program that maintains the userspace log (e.g. the famfs server) can do
> these kinds of operations?
> 
> --D

Mostly it's the code that maintains the log that needs to create stub
files and then pass in fmaps (MAP_CREATE). Changes made via the 
"front door" of a mount are ephemeral, but allowing them can have practical
value (e.g. allowing chown/chmod, which people actually seem to need to
do sometimes. Also at one point a user sent me a patch enabling symlink
creation, because some software needed that.)

But you're right that any changes we do allow are ephemeral (not logged).

Thanks!
John

<snip>