libmount: Is the 'defaults' option intentionally a no-op?

* libmount: Is the 'defaults' option intentionally a no-op?
@ 2017-05-11 11:40 W. Trevor King
  2017-05-11 12:24 ` Karel Zak
  0 siblings, 1 reply; 6+ messages in thread
From: W. Trevor King @ 2017-05-11 11:40 UTC (permalink / raw)
  To: util-linux

[-- Attachment #1: Type: text/plain, Size: 4701 bytes --]

I'm having trouble squaring the docs in mount(8) [1]:

  defaults
    Use the default options: rw, suid, dev, exec, auto, nouser,  and
    async.

    Note  that  the real set of all default mount options depends on
    kernel and filesystem type.  See the beginning of  this  section
    for more details.

and fstab(5) [2]:

  defaults
    use default options: rw, suid, dev, exec, auto, nouser, and async.

with the implementation [3]:

  { "defaults", 0, 0 },               /* default options */

where the struct fields are [4]:

  * @name: option name[=type] where type is printf-like type specifier")
  * @id: option ID or MS_* flags (e.g MS_RDONLY)
  * @mask: MNT_{NOMTAB,INVERT,...} mask

As far as I can tell, that makes 'defaults' a no-op.  For example, it
doesn't clear MS_RDONLY:

  # strace -o /tmp/trace mount -t tmpfs -o ro,defaults - /tmp/a
  # grep 'mount(' /tmp/trace
  mount("-", "/tmp/a", "tmpfs", MS_MGC_VAL|MS_RDONLY, NULL) = 0

But using ‘rw’ directly does:

  # strace -o /tmp/trace mount -t tmpfs -o ro,rw - /tmp/a
  # grep 'mount(' /tmp/trace
  mount("-", "/tmp/a", "tmpfs", MS_MGC_VAL, NULL) = 0

And as you can see in those strace logs, the presence of ‘defaults’ in
userspace_opts_map means that it doesn't get passed through in
mount(2)'s ‘data’ argument either.

I can think of a few possibilities:

a. ‘defaults’ is supposed to be a no-op placeholder for the fourth
   fstab field.  We should drop it from examples that set any other
   options (like [5]) and update the man entries [1,2] to remove the
   references to ‘rw’, ‘suid’, etc. and replace them with markers on
   the inverted settings listed by:

     $ git grep MNT_INVERT libmount/src/optmap.c

   This makes it clear that ‘defaults’ doesn't *change* anything or
   return you to the default values of some subset of settings.

b. ‘defaults’ is supposed to mean “zero mountflags” (and maybe also
   “zero data”?).  In this case, like case a, we should drop it from
   examples that set any other options (like [5]).  We should update
   the man entries [1,2] to explain the clearing.  But I don't know
   why anyone would ever use this option except on its own as a
   fourth-fstab-field placeholder (like case a).  Presumably whoever
   is inserting ‘defaults’ in the mount options could just remove all
   the earlier entries (e.g. using "bar" instead of
   "foo,defaults,bar").

c. ‘defaults’ is supposed to be shorthand for
   ‘rw,suid,dev,exec,auto,nouser,async’.  It should be implemented
   with something like:

     { "defaults", MS_RDONLY | MS_NOSUID | MS_NODEV | MS_NOEXEC | MNT_MS_NOAUTO | MNT_MS_USER | MS_SYNCHRONOUS, MNT_NOHLPS | MNT_INVERT | MNT_NOMTAB},

   (although I have no idea if using MS_RDONLY flags in
   userspace_opts_map is viable.  It probably isn't).

   Altenatively, it could be implemented by removing the entry from
   userspace_opts_map and adding a pre-processing step that replaces
   shorthand (e.g. mapping "foo,defaults,bar" →
   "foo,rw,suid,dev,exec,auto,nouser,async,bar") before iterating over
   the options in mnt_context_merge_mflags.  The man entries [1,2] are
   fine.

d. I'm missing something obvious ;).  We may want some really small
   words in mount(8) to keep others from falling into the same
   misunderstanding that I've fallen into.

Regardless of which case is correct, we may want to annotate the
inverted flags (as I mentioned in case a), since that (combined with
the existing default caveats in [6]) explains the “we will call
something close to mount(source, target, filesystemtype, 0, NULL)”
starting point, and folks might not think “let me look up the
‘defaults’ docs…” when they're trying to figure out if the default is
dev or nodev, etc.

Thoughts?
Trevor

[1]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/mount.8?h=v2.29.2#n935
[2]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/fstab.5?h=v2.29.2#n172
[3]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/libmount/src/optmap.c?h=v2.29.2#n138
[4]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/libmount/src/libmount.h.in?h=v2.29.2#n58
[5]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/fstab.5?h=v2.29.2#n65
[6]: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/mount.8?h=v2.29.2#n824

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread