1586 mount_smbfs doesn't document noacl

Review Request #911 — Created Feb. 23, 2018 and submitted

gwr
illumos-gate
1586
general

1586 mount_smbfs doesn't document noacl

Add description of acl/noacl to mount_smbfs.1m
and fix the default while we're here.

man -M usr/src/man
mount -F smbfs //server/share /mnt
and look at the permissions

Also on a system where smbfs_default_opt_acl is set, using:
mount -F smbfs //server/share /mnt
gives you ACLs, and
mount -F smbfs -onoacl //server/share /mnt
still gives you local permissions

  • 0
  • 0
  • 7
  • 1
  • 8
Description From Last Updated
gwr
gwr
jbk
  1. 
      
  2. Is there any code to prevent someone from attempting to set both 'acl' and 'noacl' mount options? Would it be worth preventing that (or noting that 'noacl' wins)?

    1. The common mount option string parsing code in vfs.c handles that, with the help of the
      mount options table earlier in this file. (Look for acl_cancel and noacl_cancel).
      The semantics are "last one wins".

    2. And perhaps I should have explained, the common (vfs.c) mount parsing code takes care of combinations of "acl" and "noacl", so by the time we get here, only one of the two calls to vfs_optionsisset with MNTOPT_ACL or MNTOPT_NOACL will return true (never both).

  3. 
      
rm
  1. 
      
  2. usr/src/man/man1m/mount_smbfs.1m (Diff revision 2)
     
     

    Update the date, please.

  3. usr/src/man/man1m/mount_smbfs.1m (Diff revision 2)
     
     
    Rather than false, it should probably be one of the two options mentioned above. So, we probably want 'The default is normally \fBnoacl\Fr.'
  4. usr/src/man/man1m/mount_smbfs.1m (Diff revision 2)
     
     

    Do we really want to document the /etc/system tunable? I'm not sure we want to promise that this kind of thing will stick around. If so, reference system(4).

    1. I'd be OK leaving this silent about the tunable. Is that better?

    2. How about making it a sharectl tunable instead?

    3. That was what I was originally thinking to do, but that turned into a bigger distraction than I want to take time for right now.

      The people likely to want this default the other way are folks building a (closed) appliance where the only use of smbfs is for data migration.
      They should be fine including an /etc/system entry in their appliance builds if they want the other default.

    4. If that's the desired end state, then yes, let's be silent about the tunable and not document / promise it. Otherwise we're going to have to figure out how that interacts with the future sharectl tunables.

  5. usr/src/man/man1m/mount_smbfs.1m (Diff revision 2)
     
     

    There's no ldap(1M) manual. There is an ldap(1) manual.

  6. usr/src/man/man1m/mount_smbfs.1m (Diff revision 2)
     
     

    Please add ldap(1) to the See Also section.

  7. 
      
gwr
jbk
  1. Ship It!
  2. 
      
seeemef@mac.com
  1. 
      
  2. usr/src/man/man1m/mount_smbfs.1m (Diff revision 3)
     
     

    This is added out-of-order.

    1. Oh, are those supposed to be in alphabetical order?
      (and by section, apparently?)

    2. mandoc formatted man pages require it, so it probably can't hurt -- first by section, then alphabetical by name

  3. 
      
gwr
seeemef@mac.com
  1. 
      
  2. usr/src/man/man1m/mount_smbfs.1m (Diff revision 4)
     
     

    Oops, now smbutil(1) is out-of-order — based on section as you observed.

    1. Oh, so all (1) then all (1M)? (sigh...)

    2. What's the command to check that mandoc is happy?

    3. AFAIK it's a manual check for man(5), with pbchk only automatically checking mdoc(5).

  3. 
      
gwr
seeemef@mac.com
  1. LGTM

  2. 
      
gwr
Review request changed

Status: Closed (submitted)

Loading...