Trying to sort this out still, but it seems that files created by ONTAP get bogus permissions via file-list-info. Note:
<file-info>
<name>filersid.cfg.bak</name>
<file-type>file</file-type>
<creation-timestamp>1325619291</creation-timestamp>
<modified-timestamp>1325619291</modified-timestamp>
<changed-timestamp>1325619291</changed-timestamp>
<accessed-timestamp>1325619291</accessed-timestamp>
<perm>1044</perm>
<owner-id>0</owner-id>
<group-id>0</group-id>
<file-size>68</file-size>
<hard-links-count>1</hard-links-count>
<inode-number>6855717</inode-number>
<acl-type>no_acl</acl-type>
</file-info>
...versus:
-bash-3.00$ stat filersid.cfg.bak
File: `filersid.cfg.bak'
Size: 68 Blocks: 8 IO Block: 32768 regular file
Device: 1bh/27d Inode: 6855717 Links: 1
Access: (0440/-r--r-----) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2012-01-03 11:34:51.665523000 -0800
Modify: 2012-01-03 11:34:51.674537000 -0800
Change: 2012-01-03 11:34:51.674537000 -0800
-bash-3.00$
It appears the internal permissions are '10440' (the leading 1 being wafl-specific) and then the resultant string is sliced to the first 4 chars (rather than masking it off). For example, chmod'ing a legit sticky bit onto the file (1440) yields:
<perm>1144</perm>
The behavior follows if a file is copied (either via ZAPI or NFS), but a new file created via NFS shows the correct behavior.
This is in the root volume, with a unix qtree style, so it wouldn't seem to be shenanigans from a mixed security style. Seeing this on both 8.0.1P5 and 7.3.2P4 systems, haven't bothered hunting for other variants.
