If you're talking about a share or export at /ifs, I'll try to make it simple. Never, Ever change the filesystem permissions of /ifs. Why? Because under there is a directory the cluster depends on to function /ifs/.ifsvar/ . If you set permissions at that level and force inheritance there is a chance you can brick or at least degrade functionality or accessibility of the cluster. In general, never use /ifs/.ifsvar /ifs/data/ or /ifs/home/ to store anything. My recommendation as I put on page 23 of the Isilon external networking guide: http://isiblog.emc.com/2015/05/emc-isilon-external-network-connectivity-guide/
is to create a root folder for each access zone like this:
/ifs/ / /
Then for administrative purposes, sure share out with run as root to domain admins, or security admins or something like that. But make it an administratively hidden share over SMB by adding a '$' to the end of the share name. Run as root can be a security team's best friend (when setting permissions), or worst enemy (when auditing who did what), so be very careful how you use it.
Thanks for your reply. Yes I understand I should not be touching the permissions for /ifs. My question is more about the shares directories under /ifs. Sorry for being unclear, let me give you an example.
The shares are created as /ifs/data/dept1/{share 1, share 2 ... }
So my question is more on the permissions and ownership of whatever is under /ifs/data i.e on dept1, dept2.... and share1, share2 etc.
Question is if share1 is owned by root from isilon and with permissions 700, I understand no one can access this share (assuming root is being squashed). But instead if this share is to be accessed by user1, is it a better idea to chown /ifs/data/dept1/share1 to user1?
Same for other shares under /ifs/data/. Should any shares be owned by root at all?
For NFS exports the best way to address both scenarios is to first read through some of the security configuration guides. They will give you the best idea on how to secure Isilon and not just for NFS but all an all round guide for multiple workflows. depending on your OneFS version you may have to use the search feature of Service center to find it but I will post links for some of the latest code versions so you know what to look for:
It is important to separate the difference between export permissions (map root to nobody) and file system permissions (using chown chgrp on file system objects). ultimately these questions come down to how do you want to administer these exports? there are many ways to achieve the same results.
If you goal is to restrict who can mount the exports themselves you can use the client list in the export so that only said group/user/IP address is able to actually mount /ifs/data/dept1/share1
exports are mountable by anyone until you populate the client list in the export itself. Once you have placed either resolvable username/group name, or IP address it then restricts mounting to only those clients listed.
If you have people mounting in /ifs/dept1 then you need use standard group and user ownership on the file system to restrict access/visibility to sub directories. i.e. create a dept1 group and make them owner of the directories so that you have to be a member of that group to be able to access the file system objects.
Thanks for your input Tracy Davis. I understand that export permissions and filesystem permissions are two different things. My question was more on the filesystem permissions. So continuing my previous example, lets say I have two directories under /ifs/data, I create them after logging on Isilon as root, the owner of this directory is root. The permissions I assign them is 700. So on filesystem it would look like this
drwx------ 2 root wheel 0B Mar 19 2015 dept1
drwx------ 2 root wheel 0B Mar 19 2015 user1
Now I export this share to be accessed via NFS. These shares are mounted on the client using /etc/fstab. The root id on this Isilon is squashed. If any user (including root) on the NFS client tries to access this share, they will not be able to access due to 700 permissions unless I change the permissions to 770. But if I chown these directories to user1, then user1 can access them.
Now my question is when we create directories on /ifs/data, should we chown them to a user/group or let Isilon root own it and open permissions for group and others, what is the good idea and best practice?
crklosterman
450 Posts
0
May 10th, 2016 10:00
PHTech ,
If you're talking about a share or export at /ifs, I'll try to make it simple. Never, Ever change the filesystem permissions of /ifs. Why? Because under there is a directory the cluster depends on to function /ifs/.ifsvar/ . If you set permissions at that level and force inheritance there is a chance you can brick or at least degrade functionality or accessibility of the cluster. In general, never use /ifs/.ifsvar /ifs/data/ or /ifs/home/ to store anything. My recommendation as I put on page 23 of the Isilon external networking guide: http://isiblog.emc.com/2015/05/emc-isilon-external-network-connectivity-guide/
is to create a root folder for each access zone like this:
/ifs/ / /
Then for administrative purposes, sure share out with run as root to domain admins, or security admins or something like that. But make it an administratively hidden share over SMB by adding a '$' to the end of the share name. Run as root can be a security team's best friend (when setting permissions), or worst enemy (when auditing who did what), so be very careful how you use it.
~Chris Klosterman
Advisory Solution Architect
EMC Enablement Team
chris.klosterman@emc.com
twitter: @croaking
PHTech
9 Posts
0
May 10th, 2016 20:00
Hi Chris,
Thanks for your reply. Yes I understand I should not be touching the permissions for /ifs. My question is more about the shares directories under /ifs. Sorry for being unclear, let me give you an example.
The shares are created as /ifs/data/dept1/{share 1, share 2 ... }
So my question is more on the permissions and ownership of whatever is under /ifs/data i.e on dept1, dept2.... and share1, share2 etc.
Question is if share1 is owned by root from isilon and with permissions 700, I understand no one can access this share (assuming root is being squashed). But instead if this share is to be accessed by user1, is it a better idea to chown /ifs/data/dept1/share1 to user1?
Same for other shares under /ifs/data/. Should any shares be owned by root at all?
Thanks!
addisdaddy20
65 Posts
1
May 11th, 2016 07:00
Hello PHTech
For NFS exports the best way to address both scenarios is to first read through some of the security configuration guides. They will give you the best idea on how to secure Isilon and not just for NFS but all an all round guide for multiple workflows. depending on your OneFS version you may have to use the search feature of Service center to find it but I will post links for some of the latest code versions so you know what to look for:
7.2.1.x
https://support.emc.com/docu60092_OneFS_7.2.1_Security_Configuration_Guide.pdf?language=en_US
7.2.0.x
https://support.emc.com/docu56051_OneFS-7.2.0-Security-Configuration-Guide.pdf?language=en_US
7.1.1.x
https://support.emc.com/docu54200_OneFS_7.1.1_Security_Configuration_Guide.pdf?language=en_US
It is important to separate the difference between export permissions (map root to nobody) and file system permissions (using chown chgrp on file system objects). ultimately these questions come down to how do you want to administer these exports? there are many ways to achieve the same results.
If you goal is to restrict who can mount the exports themselves you can use the client list in the export so that only said group/user/IP address is able to actually mount /ifs/data/dept1/share1
exports are mountable by anyone until you populate the client list in the export itself. Once you have placed either resolvable username/group name, or IP address it then restricts mounting to only those clients listed.
If you have people mounting in /ifs/dept1 then you need use standard group and user ownership on the file system to restrict access/visibility to sub directories. i.e. create a dept1 group and make them owner of the directories so that you have to be a member of that group to be able to access the file system objects.
I hope that helps,
Dan
PHTech
9 Posts
0
May 27th, 2016 01:00
Thanks for your input Tracy Davis. I understand that export permissions and filesystem permissions are two different things. My question was more on the filesystem permissions. So continuing my previous example, lets say I have two directories under /ifs/data, I create them after logging on Isilon as root, the owner of this directory is root. The permissions I assign them is 700. So on filesystem it would look like this
drwx------ 2 root wheel 0B Mar 19 2015 dept1
drwx------ 2 root wheel 0B Mar 19 2015 user1
Now I export this share to be accessed via NFS. These shares are mounted on the client using /etc/fstab. The root id on this Isilon is squashed. If any user (including root) on the NFS client tries to access this share, they will not be able to access due to 700 permissions unless I change the permissions to 770. But if I chown these directories to user1, then user1 can access them.
Now my question is when we create directories on /ifs/data, should we chown them to a user/group or let Isilon root own it and open permissions for group and others, what is the good idea and best practice?
Thanks!
Peter_Sero
4 Operator
•
1.2K Posts
0
May 27th, 2016 07:00
It makes lots of sense in many situation to give rwx permissions to the group,
so that member can access and create stuff at will.
The paradoxical thing is, with rwx for the group the actual owning user
becomes mostly irrelevant permission-wise (unless it is a non-root but real user OUTSIDE the group).
Theres one more twist, however: With directory quotas set right on the exported folder,
there comes back a good reason to choose the owner more wisely:
that user will receive the default e-mail notifications for quota alerts!
So usually we set the owner to the "head" of the group, or to someone
designated to take care on behalf.
Makes sense?
-- Peter