makefs: allow to create a immutable ffs (eg. rootfs)

[fbsd_paepcke.de]

Summary

This patch adds to makefs a new -r [read-only] command line switch. This option allows to manage the ffs superblock int8_t 'ronly' flag during fs creation.

At the moment a mount / mount -o ro actively manages (toggle) the *on-disk-state* (!?) of the attribute, but ignores the existing state. And sys/ufs seems to mange a rdonly but not ronly to figure out the existing state.

Target is to have a real working os based immutable ufs/ffs protection for rootfs/bootfs partitions, not only for (compressed) images. And Im not sure if I stumbled across a bug, missing feature or just doing something the wrong way.

[mckusick]

As you note, the existing value of the ronly flag is ignored when a filesystem is mounted. Rather it is set to reflect how the filesystem has been mounted. So presetting it to a value when creating the filesystem is pointless. If you want a filesystem in which the files and directories cannot be changed then you should set the SF_IMMUTABLE and SF_NOUNLINK flags (see chflags(2) for details) in every inode in the filesystem when you create it.

[fbsd_paepcke.de]

But the flags are all reversible via common base userland tools (runlevel/offline) similar to a simple r/w re-mount. So its no a bug, the on-disk written flag tracks only the last known r/w state, but does not enforces a state?

As fare as I can see we currently have in ffs 21 x int32_t to burn.

/* reserved for future constants */
int32_t fs_sparecon32[21];

Is there a small chance to burn one of the 21 spares
into a generic future proof mount-restrictions bit-matrix
and use the first bit as a (backwards compatible) future
real fs_read-only lock bool?

[mckusick]

In D38789#882931, @fbsd_paepcke.de wrote:

But the flags are all reversible via common base userland tools (runlevel/offline) similar to a simple r/w re-mount. So its no a bug, the on-disk written flag tracks only the last known r/w state, but does not enforces a state?

As far as I can see we currently have in ffs 21 x int32_t to burn.

/* reserved for future constants */
int32_t fs_sparecon32[21];

Is there a small chance to burn one of the 21 spares
into a generic future proof mount-restrictions bit-matrix
and use the first bit as a (backwards compatible) future
real fs_read-only lock bool?

Those flags can only be unset by the super-user (root) and if you enable secure mode they can only be reset by the super-user when the system is running in single-user mode.
It would be possible to add another flag to the existing um_flags word with the semantic that the filesystem can be mounted only as read-only (UM_READONLY). Of course it would still be possible for the superuser to clear this flag but it takes slightly more effort.

[fbsd_paepcke.de]

[...] It would be possible to add another flag to the existing um_flags word with the semantic that the filesystem can be mounted only as read-only (UM_READONLY). Of course it would still be possible for the superuser to clear this flag but it takes slightly more effort.

Yes, that is a great approach!
I will look into it / make a proposal.

In a second step, we could guard the UM_READONLY flag via the
existing FFS superblock checksum logic in way that fsck will detect
and refuse to auto-repair a manual flag clean attempt.

Thank you!

[mckusick]

In D38789#883134, @fbsd_paepcke.de wrote:

[...] It would be possible to add another flag to the existing um_flags word with the semantic that the filesystem can be mounted only as read-only (UM_READONLY). Of course it would still be possible for the superuser to clear this flag but it takes slightly more effort.

Yes, that is a great approach!
I will look into it / make a proposal.

In a second step, we could guard the UM_READONLY flag via the
existing FFS superblock checksum logic in way that fsck will detect
and refuse to auto-repair a manual flag clean attempt.

Thank you!

Have you made any progress on this issue? If not then you may want to abandon this review request.