Playing around with r151022, I may have bumped into the same issue here.
The ACE's that I set on the parent directory are nicely inherited, but
on top of that, another ACE for owner@, group@ and everyone@ is added.
Another weird thing I noticed is that these unwanted ACE's are *only*
added when the file is created directly from the command line on the
server itself or from a non-global zone that has the dataset
lofs-mounted; files created from a Windows client, through a CIFS/SMB
mount, do *not* get the extra unwanted ACE's. Now, where the heck does
that difference come from...?!
I have the relevant dataset properties set to "aclinherit=passthrough-x"
and "aclmode=passthrough".
The top-level directory has been altered up-front with "chmod -R 2777
/tank" and, to force the group-ID, "chmod -R g+s /tank".
The whole procedure of creating my datasets is not different than what I
did on r151014. I also meticulously compared the settings on both
releases, but can't seem to find any obvious difference. Or anything at all.
Here is some example output. Notice the capital "I" at the end of each
ACE line for the once that are nicely inherited, and the lack of it at
the unwanted ACE lines:
root@vm01omniosce ~ # /usr/bin/ls -lV
/tank/media_unsorted/subdir1/subdir2/subdir3/
total 1098
drwxrwsr-x+ 2 dlmgr media 2 Feb 16 19:49 from-ngz-over-lofs
user:an3s:rwxpdDaARWcCos:-d----I:allow
user:an3s:rw-pdDaARWc--s:f-i---I:allow
user:dlmgr:rwxp--aARWc--s:-d----I:allow
user:dlmgr:rw-p--aARWc--s:f-i---I:allow
owner@:rwxpdDaARWcCos:-d----I:allow
owner@:rw-pdDaARWc--s:f-i---I:allow
group@:rwxp--aARWc--s:-d----I:allow
group@:rw-p--aARWc--s:f-i---I:allow
group:mediaro:r-x---a-R-c--s:-d----I:allow
group:mediaro:r-----a-R-c--s:f-i---I:allow
everyone@:------a-R-c--s:fd----I:allow
owner@:rwxp-DaARWcCos:-------:allow #UNWANTED ACE!
group@:rwxp-Da-R-c--s:-------:allow #UNWANTED ACE!
everyone@:r-x---a-R-c--s:-------:allow #UNWANTED ACE!
-rw-rw-r--+ 1 dlmgr media 557056 Feb 16 19:49 from-ngz-over-lofs.mp3
user:an3s:rw-pdDaARWc--s:------I:allow
user:dlmgr:rw-p--aARWc--s:------I:allow
owner@:rw-pdDaARWc--s:------I:allow
group@:rw-p--aARWc--s:------I:allow
group:mediaro:r-----a-R-c--s:------I:allow
everyone@:------a-R-c--s:------I:allow
owner@:rw-p--aARWcCos:-------:allow #UNWANTED ACE!
group@:r-----a-R-c--s:-------:allow #UNWANTED ACE!
everyone@:r-----a-R-c--s:-------:allow #UNWANTED ACE!
-rw-rw-r--+ 1 admin media 0 Feb 16 19:56 from-omniosce-cli.txt
user:an3s:rw-pdDaARWc--s:------I:allow
user:dlmgr:rw-p--aARWc--s:------I:allow
owner@:rw-pdDaARWc--s:------I:allow
group@:rw-p--aARWc--s:------I:allow
group:mediaro:r-----a-R-c--s:------I:allow
everyone@:------a-R-c--s:------I:allow
owner@:rw-p--aARWcCos:-------:allow #UNWANTED ACE!
group@:r-----a-R-c--s:-------:allow #UNWANTED ACE!
everyone@:r-----a-R-c--s:-------:allow #UNWANTED ACE!
-rw-rw----+ 1 an3s media 0 Feb 16 19:56 from-win7.txt
user:an3s:rw-pdDaARWc--s:------I:allow
user:dlmgr:rw-p--aARWc--s:------I:allow
owner@:rw-pdDaARWc--s:------I:allow
group@:rw-p--aARWc--s:------I:allow
group:mediaro:r-----a-R-c--s:------I:allow
everyone@:------a-R-c--s:------I:allow
Can this be blamed on the same issue or am I looking at some other cause
here?
Any thoughts?
Muchos gracias.
Regards,
Andries
On 2018-02-16 21:11, Paul B. Henson wrote:
After we upgraded to the latest version of OmniOSce, switching from the last
OmniTI LTS release, we ran into a fairly big problem with ACL inheritance,
which results in unexpectedly insecure file permissions :(.
After a short discussion on the ZFS developer mailing list:
https://illumos.topicbox.com/groups/zfs/discussions/Te5cbb71851130ac1-M486e4
bd93
ace9f7314003f66
We determined this was a problem introduced by issue 6764, and I opened a
new issue regarding it:
https://www.illumos.org/issues/8984
I asked on the ZFS developer mailing list if anyone might be willing to
spend a little time fixing this regression:
https://illumos.topicbox.com/groups/zfs/T821c96dfa2b1306d-M13ef4f3ea9d83b7f3
91859a1
but I haven't heard anything. It should be fairly simple, just adding back
in a little bit of logic the previous change took out; however, I don't
currently have an up-to-date build environment and would rather not have the
overhead of putting that together right now just for this little fix.
Are there perhaps any OmniOS developers who might be kind enough to squash
this for us? We are getting a lot of complaints from users and potentially
leaking sensitive information because of it.
Thanks much.
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss