I haven't yet seen a mixed permission model that works well. Maybe they're out there, but the problem is just hard. It's easy to set yourself up such that you have conflicting permissions. Can/should you allow a Windows user to be able to write the file from Windows yet deny access via NFS? I can see some environments where that might be desirable (you might want to give your Windows read-only access to HPC data yet not allow a virus to corrupt the data) and others where that's going to drive users nuts.
I've been going under the impression that you just have to pick one model per file and never mix them. With AD having a decent ACL model and LDAP/NFS3 not having one at all, the problem does get ugly and I rarely see Unix admins asking to switch to AD.
I sort of agree with you on the statement of keeping data between the two environments separated if we are going to configure the Isilon to support mixed environments. I sort of figured that this would create a bit of a permissions management and process nightmare. I will make the recommendation that we keep data between the 2 environments separate unless I hear from someone who has successfully accomplished this mix.
My 2 cents (full disclosure; former Isilon CTO Americas)
In my experience, Ed is right - it's hard. But it's not hard strictly from the filesystem's POV, really. The method of generating either 'Unix' or 'Windows' permissions from the other is straightforward. ACLs are the definitive way to control access to directories and files, regardless of the protocol or OS used to access them.
What is hard is the world of authentication providers - AD and LDAP, and the 'worlds' they grew up in, to use a phrase. They use two completely different methods to provide authentication - proving "you are who you claim to be". This, in my opinion, is the root cause of "permission problems" that users of filesystems encounter - and not just with Isilon.
Then there are the companies that literally give (or worse yet, assume) the same person different 'roles' or 'authority', depending on which provider he or she authenticates through...literally the classic 'multiple personality' syndrome. As you can imagine, this can be exceedingly difficult to manage while trying to leverage the efficiencies of a single namespace with a single set of directory and file permissions. That's one reason why the concept of access zones and tying a given provider to them is helpful; in this manner, even with a single ACL set on a given file, there is a control point where the same person (or groups of people) can access that file in different ways, arbitrated through the different authentication providers.
I apologize if I have only raised the confusion level to a higher state :-)
My point is this - don't blame the filesystem for "permission problems". It's doing what you tell it to do. Go back and study the way your business authenticates its users...from there the path to smooth operation in a mixed authentication/role/authority world becomes much easier.
Anonymous User
170 Posts
1
April 9th, 2015 06:00
I haven't yet seen a mixed permission model that works well. Maybe they're out there, but the problem is just hard. It's easy to set yourself up such that you have conflicting permissions. Can/should you allow a Windows user to be able to write the file from Windows yet deny access via NFS? I can see some environments where that might be desirable (you might want to give your Windows read-only access to HPC data yet not allow a virus to corrupt the data) and others where that's going to drive users nuts.
I've been going under the impression that you just have to pick one model per file and never mix them. With AD having a decent ACL model and LDAP/NFS3 not having one at all, the problem does get ugly and I rarely see Unix admins asking to switch to AD.
chjatwork
2 Intern
•
356 Posts
0
April 9th, 2015 07:00
Ed,
I sort of agree with you on the statement of keeping data between the two environments separated if we are going to configure the Isilon to support mixed environments. I sort of figured that this would create a bit of a permissions management and process nightmare. I will make the recommendation that we keep data between the 2 environments separate unless I hear from someone who has successfully accomplished this mix.
peglarr
99 Posts
0
April 9th, 2015 08:00
My 2 cents (full disclosure; former Isilon CTO Americas)
In my experience, Ed is right - it's hard. But it's not hard strictly from the filesystem's POV, really. The method of generating either 'Unix' or 'Windows' permissions from the other is straightforward. ACLs are the definitive way to control access to directories and files, regardless of the protocol or OS used to access them.
What is hard is the world of authentication providers - AD and LDAP, and the 'worlds' they grew up in, to use a phrase. They use two completely different methods to provide authentication - proving "you are who you claim to be". This, in my opinion, is the root cause of "permission problems" that users of filesystems encounter - and not just with Isilon.
Then there are the companies that literally give (or worse yet, assume) the same person different 'roles' or 'authority', depending on which provider he or she authenticates through...literally the classic 'multiple personality' syndrome. As you can imagine, this can be exceedingly difficult to manage while trying to leverage the efficiencies of a single namespace with a single set of directory and file permissions. That's one reason why the concept of access zones and tying a given provider to them is helpful; in this manner, even with a single ACL set on a given file, there is a control point where the same person (or groups of people) can access that file in different ways, arbitrated through the different authentication providers.
I apologize if I have only raised the confusion level to a higher state :-)
My point is this - don't blame the filesystem for "permission problems". It's doing what you tell it to do. Go back and study the way your business authenticates its users...from there the path to smooth operation in a mixed authentication/role/authority world becomes much easier.
Cheers
Rob