NFS and deny permissions

There's always "bonus features" that get stuck into products that may or may not be useful.   But the hard part of all this is when you start using that "bonus feature", then your locked in and... BANG!  They gotcha!  Then when you want to migrate off....   BOOM! You can't. 
Is it really locking you in?  Maybe... maybe not.  There are certain features that are life savers and you need to make a decision on whether or not to really abandon that product and go with another that doesn't have that feature.   For other features, you just need a way to do the same ting in another way.
Once of these features is a "deny permissions" setting on another NAS vendor's system.  This in essence denies anyone from being able to change the permissions of a file via NFS.  This means no chmod's allowed.  Is that a good thing?  Well maybe.  It may allow the permissions to be set initially on a file but all subsequent changes are denied.  This is great, but there's other mechanisms in the world to provide the same or similar behavior.  And why do you really need this?  For one, some unified permissions schemas are so insecure, this is a way to be "secure".


Deny Permissions on NFS the easy way.  With NTFS.
Lets look at ONTAP and the "deny permissions" flag.   How can you "deny permissions" for chmod in ONTAP?   Well, the easiest way is to create an NTFS volume (or change the security style of an existing volume).   If an NFS client tries to perform "chmod" operations to the files or directories in that volume, the operation will be denied.  This can cause problems with some Linux applications that can't have chmod return errors; like vi.  For this, ONTAP has a setting called "ignore security operations on NTFS volumes" (-ntfs-unix-security-ops ) .  When this is set, ONTAP will return a success to the chmod, which makes the application happy, but in reality, it just discards the chmod op.  This way, the only way to change the permissions is via Windows or SMB.  Now you can use Windows ACLs to further limit permissions and access.  Why is this good?  Well, you can set the initial permissions at the volume level and then be sure that all files and folders inherit the exact same permissions without fail.  If you don't allow SMB access, then noone will be able to change it.

In action?   Why sure.  Here we go.  (Assuming SVMs, CIFS server, protocols, and other Vserver is already done)
1.  Create an NTFS volume
cluster::> volume create -vserver svm0 -volume no_chmods -aggregate aggr1_node1 -size 100G -security-style ntfs -junction-path /no_chmods
2.  Change the setting to ignore the NFS chmods

cluster::*> vserver nfs modify -vserver svm0 -ntfs-unix-security-ops ignore

Then what happens?  Well you need to create the export policy for the volume, but then you just mount the volume and viola.....  there's no way to chmod.  You can't chown either from an NFS client.  You can only change the ACL from an SMB client.

So here I have the volume mounted, touched a file and then chmod'd it.  As you can see, there was no error to the chmod, just a return, but the chmod did nothing.  This is because when ONTAP is presenting an NTFS style volume to NFS clients, NFS security operations cannot  modify the file permissions.  

Bonus Material:   The NTFS permissions can even be locked down beyond what's listed via SLAG (Storage Level Access Guard) in ONTAP.  SLAG allows you to put another set of ACLs on the volume and further deny (SLAG can only limit and not allow more permission) access to the files.

Deny permissions on NFS with NFSv4 ACLs on UNIX style volumes.

You don't want to use NTFS style volumes?  There definitely is another way of limiting access to chmod, and that's via NFSv4 ACLs.  Those ACLs work similarly to NTFS ACLs and can deny rights to change permissions and ownership if necessary.  If you are not familiar with NFSv4 ACLs, go visit my favorite resource for them at die.net (https://linux.die.net/man/5/nfs4_acl).  There's some good resources I've relied on forever.  Here's the catch....  you can't limit the chmod for the file owner.  Bummer.  

How do you do this one?  Let's see.....

1.  Allow NFSv4 on the NFS server and allow the ACLs.  We're assuming you already have an SVM, an export policy and a volume exported.

cluster::> vserver nfs modify -vserver svm0 -v4.0 enabled -v4.0-acl enabled -v4.1 enabled -v4.1-acl enabled

2.  Enable the setting to force the ACL over mode bits to be applied on new files & folders

cluster::*> vserver nfs modify -vserver svm0 -v4-inherited-acl-preserve enabled

3.  Enable the setting to not clobber the ACLs when an actual chmod is run by someone who is allowed

cluster::*> vserver nfs modify -vserver svm01 -v4-acl-preserve enabled

Then you can mount the volume either NFSv3 or NFSv4 and the same ACL is applied to both protocols.  First you do have to set the ACL properly for this to work.  Let's see how this is done.

First set the proper permissions.  What you don't want in there is "write attributes" (capital T), write named attributes (capital N..  and it's optional) and write ACL (capital C)

# nfs4_setacl -a A::testerdlu0002@ntap.local:rwaxtncy testfile

This will allow the user to perform any operation except modify the ACL, owner and mode bits.

So now, when the user tries to chmod the file... viola.. permission denied!

Can you also do it with SLAG and UNIX style volumes??

Well sure you can.  You have to be a little careful with SLAG though.  There are a few caveats.  First, you have to have a CIFS server created on the SVM.  Easy enough.  Second, you MUST have Unix->Windows usermapping working perfectly.  Without it, SLAG won't be applied properly since it used the Windows user creds to apply it.  Third, it also looks to have an implicit default DENY rule at the end of it.  No bueno if you want to ensure the same access.

Here's the policy I was using that had some success.  Notice the 2 deny rules at the top.  The access rights hex value (c0110) translates to WriteEA,Write Attributes, Write DAC and Write Owner in the NTFS permission world.  This basically denies everyone the right to chmod.

cluster::*> file-directory ntfs dacl show -vserver svm0

  (vserver security file-directory ntfs dacl show)

Vserver: svm0

  NTFS Security Descriptor Name: deny_write_attr_everyone

    Account Name     Access   Access             Apply To

                     Type     Rights

    --------------   -------  -------            -----------

    BUILTIN\Users    deny     c0110             this-folder, sub-folders, files

    CREATOR OWNER    deny     c0110             this-folder, sub-folders, files

    BUILTIN\Administrators

                     allow    full-control      this-folder, sub-folders, files

    BUILTIN\Users    allow    full-control      this-folder, sub-folders, files

    CREATOR OWNER    allow    full-control      this-folder, sub-folders, files

    NT AUTHORITY\SYSTEM

                     allow    full-control      this-folder, sub-folders, files

6 entries were displayed.

The bottom line?   Well... to be honest, the only reason that some NAS appliances have this "deny chmod" feature is in order to keep files secure and to enforce a consistent set of permissions across a volume.  Well...  if you really want to do that, let's use NTFS volume security.  That's the easiest.  Then you can manage permissions once when the volume is created (apply inheritable permissions at the volume root) and then its applied everywhere.  If you REALLY Need it in a UNIX style volume.....  You can use NFSv4 ACLs to deny write attributes.  If you ABSOLUTELY need it to apply to the owner too, look into using SLAG.