Permissions question

[Thomas Spear]

Hello,

We have recently created a new share on our new Isilon farm and created the volume with mixed mode permissions, so that both Windows and *nix can have security permissions. On this particular share, we're having some trouble nailing down the source of our linux permissions problems.

I'm a linux guy at my company, however another person handles the Isilon infrastructure, so I'll need to draw references from the linux world to explain to you guys, and hope that isn't a problem.

We have an LDAP setup for linux to authenticate against AD, and we have entered the LDAP server information into the Isilon GUI. We know that LDAP is working because another share on there is working properly, permissions and all. We have several linux groups defined in LDAP, and mapped to high UID numbers (5000 and up).

We have a few different problems, so I'll detail them below:

0) Preface: We haven't tested CIFS permissions to find out what files would look like as far as ownership goes on the linux side, but #3 below details how we will want it to work.

1) When we mount the share on linux, what we're seeing is that if we create a file as root, its owner is set to the nfsnobody user, rather than root, and group owner is also nfsnobody instead of root. Whereas if we create a file as a normal user, then the file is owned by the user and his primary group. We migrated data from another volume that already was owned by root, and those files maintained their root:root ownership.

2) We want the share to be owned by a group other than root, so that only that one group can access the share, however nobody can change the group on the files and folders, including on the folder that is the actual share.

  a) I'm personally in the staff group (LDAP defined as gid 10), the datamgt group (LDAP defined as gid 5012), and the root group (LDAP defined as gid 0), and even I cannot change the group owner, neither as root nor as my normal user. I've tried through linux, and it just tells me permission denied or some such.

  b) The storage guy is able to change the group on the share and on the files and folders in the share from the GUI, however the datamgt group is not showing up in the dropdown, whereas it does show up in the dropdown for the other share which is working properly.

  c) If we change the group to admin on the GUI, then it gets the staff group on the linux side (presumably because admin is gid 10 on the Isilon.)

  d) If we change it to root on the GUI, then it gets the root group on the linux side.

  e) So its not as if changing the group is not working at all, but more like it's not pulling the group memberships from LDAP for some reason and so it denies linux users from making changes.

3) What we want is for the root user and datamgt group to own the share, and then for whomever creates the files to own them while retaining datamgt as the group owner. We'd also like for that to happen if someone creates a file on the share via Windows. Additionally, we'd like files created by root to be owned by root:root rather than nfsnobody:nfsnobody

Hopefully that clearly explains the problem enough for someone to help us get this fixed, but if you need more info, please let me know.

[Jerry Uanino]

for #1, map root to root. by default it's squashed, this is equivalent to "root squash" in other nfs devices or if you were serving nfs fro ma linux fileserver.  The isilon gui as an option for map root:root I believe, this is a per export setting.

--
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/groups/opt_out.

[Thomas Spear]

Thanks. I've done it and it works.

Also, we've resolved the other issues. The storage guy found how to get datamgt into the dropdown and so then he was able to do a recursive chgrp on the Isilon itself.

Thank you,

Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/isilon-user-group/0fkY0K6XXvQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to isilon-user-gr...@googlegroups.com.

[Peter Serocka]

On Fri 4 Oct '13 md, at 23:01 st, Jerry Uanino <jua...@gmail.com> wrote:

> for #1, map root to root. by default it's squashed, this is equivalent to "root squash" in other nfs devices or if you were serving nfs fro ma linux fileserver. The isilon gui as an option for map root:root I believe, this is a per export setting.
>
>

But then root will have full power over all users's files,
is that intended => Thomas?

The key to answering most of the questions is to understand
the implications of having the file ownerships and permissions stored
on the Isilon EITHER in the UNIX way OR via ACLs, the Windows way.

With UNIX permissions "on disk", the exact mapping of AD users
to Unix users must be made clear, see refs below. When mounting
via CIFS to Windows clients, the UNIX permissions appear as
"synthetic ACLs", which go pretty straightforward.

With ACLs permissions "on disk", the meaning of AD users
and access control on Windows clients should be also straightforward
(as straightforward as ACLs can get). On Unix NFS clients,
the shown permission bits are "synthetic" then - and are
a mere approximation to what a file's ACL actually expresses.
Deeper reflections reveal that this is impossible in general,
therefore a thorough understanding of that process is required
(see refs below). This is the key part that is actually
Isilon-specific, compared to the handling of plain
Unix or plain Windows shares. After all, effective are the ACLs
on the server (Isilon) side, not the listed bits on the client!

The best reference is
http://www.emc.com/collateral/software/white-papers/h10920-wp-onefs-multiprotocol.pdf

Plus these exellent Q&A sessions in the Isilon Support Forum:

Ask the Expert: AIMA: Everything you wanted to know but were afraid to ask.
(AIMA = Authentication, Identity Management, and Authorization)
https://community.emc.com/message/758454

Ask the Expert: SMB Protocol on an Isilon Cluster
https://community.emc.com/thread/177333

You will need to get your storage team involved with this, I guess…

Cheers

-- Peter

[Thomas Spear]

"But then root will have full power over all users's files, is that intended => Thomas?"

Yes. Root access is restricted to certain privileged users, and my team. Ironically, now that the permissions are fixed, I need to add root to the datamgt group to give him access to the share. Since my team is all in the datamgt group anyways, we can just do what we need to do with our unprivileged accounts, rather than root, so we shouldn't ever have an issue of root owning files, since he's locked out of the directory.

Thank you,

Thomas

You received this message because you are subscribed to a topic in the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/isilon-user-group/0fkY0K6XXvQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to isilon-user-gr...@googlegroups.com.

[Peter Serocka]

Great! I'm just not sure wether you can -- without use of ACLs --
arrange for new files to obtain the datamgt group automatically, though…

-- Peter

[Thomas Spear]

We've managed that on the Linux side thanks to linux style commands like chmod -R 2770. I'm working with an issue on Windows now so I'll get to see whether that works or not shortly.

Thank you,

Thomas