RBAC and Isilon chmod Command

[gtjones]

I have a need to allow my users manage ACLs from the command line using the Isilon chmod command. Because clients don't have the special chmod command used by Isilon, they need to login to one of the nodes and execute the command. How do I do this using RBAC/sudoers without giving them the keys to the kingdom? 

I understand that they can manage the ACLs via Windows but they want to use scripts to manage them. 

Anybody have experience with this and what's a best practice?

Thanks,

Greg

[Neproshennie]

Greg,

Are the users needing to be root in order to change the permissions? Users can use the chmod command to manipulate ACLs as long as they have the appropriate permissions to view and edit the discretionary access control list (DACL). Typically users shouldn't have elevated privileges to use chmod due to the security risk of changing permissions on another path or mistyping a command resulting in catastrophic permissions issues throughout the cluster. It's not going to be easy to restrict a user to run the chmod command within their own respective path.

--Jamie Ivanov

[Adam Fox]

-- Adam Fox

adam...@yahoo.com

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Fox]

If they want to manipulate permissions via scripts, why not PowerShell?  

-- Adam Fox

adam...@yahoo.com

On Feb 24, 2015, at 9:33 AM, Neproshennie <jamie....@gmail.com> wrote:

--

[Neproshennie]

+1 on PowerShell.

Otherwise:
* cacls
* icacls
* xcacls
* subinacl

https://technet.microsoft.com/en-us/library/bb490872.aspx

I keep a copy of *cacls tools on my emergency repair thumbdrive.

--Jamie Ivanov

[gtjones]

Good point Jamie.

I'll give them SSH access to the storage nodes, then the DACLs will define who can and can't change permissions. I think they're used to having root access to mange their ACLs on a Linux box serving files over NFS. Making sure the DACLs have the right permissions to allow this will require planning but this is reasonable.

What would be best is to allow them to mange the DACLs from a client but I don't think this is possible. I really don't want users logging into the storage nodes.

Greg

[gtjones]

Adam,

I thought about giving this answer but didn't. These are scientist that have been using shell scripts for years to manage their data. The thought of them having to learn PS to manipulate permissions wouldn't fly. Their time is too valuable to have them learning programming languages. It is an option though if I can't find a solution.

Thanks,

Greg

[Peter Serocka]

Greg, would give NFS4 a try? at least on one dedicated client?

-- Peter

[Neproshennie]

Of course you can give "creator_owner" full permissions with "dir_gen_all" which should encompass reading/writing of the security descriptors. Non-root users will have some limitations but they should have the access they need with a finely tuned ACL and inheritance.

Like Pete suggested, you can use NFSv4 due to NFSv4's ability to use NFSv4 ACL manipulation tools. OneFS will translate the NFSv4 ACL commands to equivalent NTFS and there have been some quirks in the past. Keep in mind that NFSv4, while similar, is going to require you to add user access to the entire tree for read and execute thanks to the NFSv4 virtual root and it's going to be a stateful protocol versus the statelessness of NFSv3 so there may be I/O interruptions during a failover event (which may be beneficial in preventing stale locks).

--Jamie Ivanov

[Adam Fox]

All better options than logging into the nodes.  The syntax for these is simple enough that a scientist who can write a shell script or figure out the extended syntax of OneFS chmod command should have no trouble using these.

-- Adam Fox

adam...@yahoo.com

[Richard Kunert]

I have a similar requirement, but there’s no way I’m giving users ssh access to our cluster - someone would eventually break something. I’ve just started looking into using the API to script ACL changes, it doesn’t look too bad. Another thought would be to use the API to kick of a repair permissions job, since that would fix many of the user problems.

And no, I don’t expect my bioinformaticians to learn json. I’m going to have to write some code.

From the 7.1.1 API document:

Sets the access control list of the directory.

Request syntax

PUT /namespace/<access_point>/<container_path>/<container_name>?acl HTTP/1.1
Host: <hostname>[:<port>]
Content-Length: <length>

Date: <date> Authorization: <signature>

{
"owner":{

"id":"<owner id>", "name":"<owner name>", "type":"<type>"

}, "group":{

"id":"<group id>", "name":"<group name>”,

"type":"<type>" },

"authoritative":"acl"|"mode", "mode":"<POSIX mode>", "action":"<action_value>", "acl":[

      {
         "trustee":{

"id":"<trustee id>", "name":"<trustee name>", "type":"<trustee type>"

},
"accesstype":"allow"|"deny", "accessrights":"<accessrights_list>", "inherit_flags":"<inherit_flags_list>", "op":"<operation_value>"

} ]

} 

--

Richard Kunert

[Neproshennie]

Richard,

You would still have to authenticate as a user that has API access via RBAC and also have permission to change the ACL on a path otherwise this could be a security risk. On the other hand, if your script did the user account validation and what path they should be changing permissions on, you could easily get away with using the API via an elevated account due to the fact the API instructions would (or should) not be visible to the user. I have a number of Python based web applications that I could incorporate that into for a fun project on a weekend.

--Jamie Ivanov

[Richard Kunert]

Yes, I realize the API can give away the keys to the car. Security needs to be considered.

So as I test, I just used the API to change an ACL as follows:

I created a file called acltemplate:

{
"authoritative":"acl", "action":"update",
"acl":[
{
"trustee":{ "name":"rkunert" },
"accesstype":"allow", "accessrights":[ "dir_gen_all" ], "inherit_flags":[ "object_inherit, container_inherit" ], "op":"add"
} ]
}

And I uploaded it using curl:

curl -v -u "root" -k -s -T acltemplate https://mycluster:8080/namespace/ifs/test?acl


Result:

Isilon2-1# ls -dale test
drwxrwxr-x + 2 root wheel 0 Feb 24 11:29 test
OWNER: user:root
GROUP: group:wheel
0: user:rkunert allow dir_gen_all,object_inherit
1: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
2: group:wheel allow dir_gen_read,dir_gen_execute
3: everyone allow dir_gen_read,dir_gen_execute

--
Richard Kunert

[Richard Kunert]

Whoops, the inherit_flags list was missing a couple of quotes, each list item needs to be quoted - that’s why container_inherit didn’t get set. Corrected:

{
"authoritative":"acl", "action":"update",
"acl":[
{
"trustee":{ "name":"rkunert" },
"accesstype":"allow", "accessrights":[ "dir_gen_all" ], "inherit_flags":[ "object_inherit", "container_inherit" ], "op":"add"
} ]
}

--
Richard Kunert

[Adam Fox]

Actually, you are just using RAN (Restful Access to the Namespace) and not PAPI (Platform API). This is much safer with respect to “the keys” as you say.

You would simply have to use RBAC to grant the user Namespace access. Permissions still apply in the namespace so the user will only be able to modify ACLs if they would be allowed to over a NAS protocol and no administrative access would be required. When the user applies for a token, he would request namespace only (not platform access) and then that token could be used to do whatever the user could do via SMB.

I hadn’t considered it before since Powershell was off the table, but if they don’t mind a little REST/JSON coding, it should work just fine.

— Adam Fox
adam...@yahoo.com

[Richard Kunert]

The EMC document just calls it the OneFS API.

I do see one problem with the API approach. I’m not seeing any option in the ACL setting API for recursion, so you would have to handle that in your own script. That would result in a lot of network traffic for large directories. It would be possible to start a repair permissions job to handle the recursive part and inherit the parent permissions, but that requires root privileges.

--
Richard Kunert

[Adam Fox]

Then your best bet, IMHO, is to use a tool like calcls or xcacls.

-- Adam Fox
adam...@yahoo.com

[gtjones]

Thanks for the conversation. I'm going to pursue the NFSv4 route and if that doesn't work use Windows ACL manipulation tools.

Greg

[Neproshennie]

Greg,

Please keep in mind that NFSv4 uses principal names so the NFSv4 domain in the client's idmapper needs to be the same as the NFSv4 domain on the cluster.

NOTE: NFSv4 domain is separate than an Active Directory domain. Some people have them different and some keep them the same. OneFS can be configured to ignore the NFSv4 domain that comes in over the wire. NFSv4 name resolution is handled on the client which would account for seeing "nfsnobody" owner/group responses which typically indicate a NFSv4 domain mismatch OR the user doesn't exist on the local system for name resolution.

Also, you will need some kind of name to UID record stored, whether manual idmapper entries on the cluster or from AD, due to NFSv4 using principal names instead of UIDs like NFSv3. Consider user jamie@nfsv4domain will come in over the wire and access a file that has an ACE for "jamie" with the rules of "file_gen_all". When looking at the numeric (ls -lend) user value for that ACE, I see it has an on-disk-identity that is a UID of 100002 (autogenerated). Even if jamie's UID on the Linux client is set to 100002, accessing the file will result in "access denied". One way around this is to have the user "jamie" part of an AD domain that is the default domain for AD so the cluster will see "jamie" then prepend the domain which will resolve the SID and build the authentication token with the corresponding UID but map-lookup-uid may then be required which will also affect all NFSv3 users to that specific export.

Switching to NFSv4 isn't as simple as flipping a switch and autopilot flies the plane. You can have both NFSv3 and NFSv4 running at the same time BUT clients will automatically try to mount with the highest NFS version number before falling back to the next lowest unless "vers=3" or "nfs3" is specified in the client's mount options (please refer to your distribution NFS mounting parameters). I'm not trying to scare you away from NFSv4 but I want to make sure that you have your bases covered and it is reasonable to expect some wrinkles while setting up NFSv4.

--Jamie Ivanov

[Dan Pritts]

I'd be interested in hearing how it all works out with NFS4.  I poked around a little bit, and found that the RHEL6 NFS4 ACL tools were, at best, minimal.  I also looked for code that I could easily steal; I didn't find anything good for perl or python. 

gtjones wrote:

--

You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Dan Pritts
ICPSR Computing & Network Services
University of Michigan

[Neproshennie]

Dan,

Code for what? Utilizing the API to manipulate permissions?

--Jamie Ivanov

[Dan Pritts]

Code for modifying NFS4 acls from the client. 

Neproshennie wrote:

Dan,

Code for what? Utilizing the API to manipulate permissions?

--Jamie Ivanov

On Thursday, February 26, 2015 at 2:33:16 PM UTC-6, Daniel Pritts wrote:

I'd be interested in hearing how it all works out with NFS4.  I poked around a little bit, and found that the RHEL6 NFS4 ACL tools were, at best, minimal.  I also looked for code that I could easily steal; I didn't find anything good for perl or python. 

[Jamie Ivanov]

I've had the best luck with Solaris in regards to NFSv4 support. On Linux, the {get,set}_facl commands are really all you have. There isn't direct support via pythons standard libraries and most people call those external binaries but I saw that this looked interesting: https://gitorious.org/ufo/nfs4-acl-tools/source/HEAD:

I haven't looked into it much to see whether it would be useful.

Jamie Ivanov / KC9LFD
Mobile: 608.399.4252
http://www.linkedin.com/in/jamieivanov
-- -- -- -- -- -- -- -- -- -- -- --
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.