Unsolved
This post is more than 5 years old
15 Posts
0
3942
Membership & Roles
Hello all!
I have some questions:
- Different between root vs admin user? I see in Roles (sysadmin, securityadmin role) only have admin user, but why using root user still can configure isilon system?
- Different between File:System vs Local:System and wheel group vs admin group?
Please point to me! Thanks!
sluetze
300 Posts
2
January 13th, 2016 05:00
Hi,
root (uid 0) is a builtin unix user. He "lives" under the permission-layer thus, permissions don't exist for root. This causes (and this is wanted by unix-design) his ability to control the complete system in all ways. Since no permissions exist for root, he can do whatever he wants to do, even if you try to deny access to him.
--> you can do the following:
$ echo "root wont see it" > /ifs/data/testfile
$ chmod 700 /ifs/data/testfile
$ chown admin:wheel /ifs/data/testfile
this sets (unix-)permissions that ONLY admin has access to /ifs/data/testfile
as root:
# cat /ifs/data/testfile
The admin (uid 10) is a "normal" user, which is built in and is enabled by RBAC to fully administrate the "isilon"-part of the system.
FILE:System
Authoritative third/partz source of user and group information to the cluster.
FILE:local
Authentication and lookup facilities for user accounts that wer added by an administrator. Local Groups can include Built-in groups and Active Directory Groups as members
wheel and admin group... puh. don't know if that is relevant... and can't differentiate them enough
Take alook on docu56051 (Security Configuration Guide) which tells you a lot over authentication
Rgds
--sluetze
RobChang-Isilon
136 Posts
1
January 13th, 2016 11:00
Hi,
I can briefly speak to File:System vs Local:System.
I was told recently by a development lead that we all should be creating users in the LOCAL:System, and not in FILE:System. This has something to do with security descriptors, in that LOCAL:System tracks them fully when operating Isilon in a mixed environment (UNIX and Windows). Whereas FILE:System is reserved for some of the system/built-in users like root and insightiq, and primarily used for a UNIX-only environment. And since most Isilon customers are operating their clusters in a mixed environment, we should all just use LOCAL:System.
I'll have to do some digging to find out more details if you need to know. But the official guidance is to use LOCAL:System and not FILE:System for your users.
Hope this helps.
- Rob
crklosterman
450 Posts
0
January 14th, 2016 07:00
In addition to Rob's comment, just a little perspective. I would always advise using an external auth provider, but if you must create your own local users and groups, I would suggest using the file provider, but not the builtin file:system, but create your own. Why? It comes down to DR. If you look at a file provider, what is it really? Just 3 files, passwd, group, and spwd.db binary. When you create your own file provider you can store it wherever you want, so let's say your cluster is called isilon01, you could store the files at: /ifs/isilon01/system/auth/ . Now for the sake of argument say that you protect that whole 'system' folder with SyncIQ to another site. You can actually tell that other site about that auth provider (it'll be read-only of course), but you can do it, and have those users and groups always as in-sync as your data, and protected at the DR site. That option is not possible with anything you do to the builtin local:system or file:system, so even though SyncIQ might protect the data if those users or groups are given any file access when you failover they won't be able to get to it.
Hope this helps, again just my perspective,
Chris Klosterman
Advisory Solution Architect
EMC Enablement Team
chris.klosterman@emc.com