Index | Thread | Search

From:
Crystal Kolipe <kolipe.c@exoticsilicon.com>
Subject:
Re: [patch] mount_mfs allow setting permissions manually
To:
Rafael Sadowski <rafael@sizeofvoid.org>, tech@openbsd.org
Date:
Thu, 24 Jul 2025 16:50:52 -0300

Download raw body.

Thread
On Mon, Jul 21, 2025 at 06:48:06PM +0100, Stuart Henderson wrote:
> On 2025/07/21 04:18, Crystal Kolipe wrote:
> > On Sun, Jul 20, 2025 at 12:59:09PM +0100, Stuart Henderson wrote:
> > > On 2025/07/20 04:52, Crystal Kolipe wrote:
> > > > Do we also need to clarify in the man page what happens if both -p and -P are
> > > > used at the same time?  In that case, -p is ignored and the permissions from
> > > > the directory specified with -P are used.
> > > > 
> > > > I'm wondering if that is even the desired behaviour, maybe -p should always
> > > > override even when -P is specified.  But if nobody has an opinion on this
> > > > I'm OK with the current proposal.
> > > 
> > > fwiw, I think I would expect -p to be used "over the top" of -P's
> > > permissions if both flags are specified.
> > 
> > This version should address that.  Now if both -p and -P are specified on the
> > command line, the permissions of '.' are set to whatever was specified as the
> > argument to -p.
> > 
> > I'm assuming that's what you meant, although "over the top" could also be
> > interpreted as 'a logical AND of both the permissions gained from -P and those
> > specified with -p', (which could in itself could be considered an over the top
> > suggestion in another sense, thereby causing an infinite mental loop :-) ).
> > 
> > The chmod of '.' is not expected to fail, so we only print a warning if it
> > does, and continue with the inherited permissions.  Should this be a hard
> > error?
> 
> That seems reasonable. fwiw, the code bits are OK with me.
> 
> I'm not sure about the text about "can create security issues" in
> the manual though, I think I'd stick to just describing the action
> of -p.

Here's a new manual diff with the security issues text removed and an examples
section showing how to mount an mfs /tmp at boot.

Does anyone have any more opinions on this?  Any further OKs?

--- newfs.8.orig	Mon Apr  7 04:25:02 2025
+++ newfs.8	Thu Jul 24 20:35:55 2025
@@ -67,6 +67,7 @@
 .Op Fl m Ar free-space
 .Op Fl O Ar filesystem-format
 .Op Fl o Ar options
+.Op Fl p Ar mode
 .Op Fl P Ar file
 .Op Fl s Ar size
 .Ar special node
@@ -270,7 +271,8 @@
 are as described for
 .Nm ,
 except for the
-.Fl o
+.Fl o ,
+.Fl p
 and
 .Fl P
 options.
@@ -284,6 +286,11 @@
 See the
 .Xr mount 8
 man page for possible options and their meanings.
+.It Fl p Ar mode
+Set permissions on the mount point after the mfs filesystem has been mounted.
+The
+.Ar mode
+argument must be specified in octal notation.
 .It Fl P Ar file
 If
 .Ar file
@@ -295,9 +302,11 @@
 contents of the FFS file system contained on the device.
 .El
 .Pp
-If the
+If neither of the
+.Fl p Ar mode
+or
 .Fl P Ar file
-option is not used, the owner and mode of the created mfs file
+options is used, the owner and mode of the created mfs file
 system will be the same as the owner and mode of the mount point.
 .Sh ENVIRONMENT
 .Bl -tag -width COLUMNS
@@ -308,6 +317,11 @@
 .Nm
 defaults to the terminal width, or 80 columns if the output is not a terminal.
 .El
+.Sh EXAMPLES
+The following line added to /etc/fstab will mount a 512MB mfs filesystem on
+/tmp at boot time, setting appropriate permissions:
+.Pp
+.Dl swap /tmp mfs rw,nodev,nosuid,-s=512m,-p=01777 0 0
 .Sh SEE ALSO
 .Xr disktab 5 ,
 .Xr fs 5 ,