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>
