On-Disk Identity and UID GID Allocation

[gtjones]

Does anybody have a good definition of what "on-disk" identity means? I have all the multiprotocol papers written by EMC and I'm struggling with the concept of "on-disk". Related to that, what is the difference between these two settings is it relates to UID/GID auto creation? 

1., isi auth settings mapping view

  GID Range Enabled: Yes

    GID Range Min: 1000000

    GID Range Max: 2000000

  UID Range Enabled: Yes

    UID Range Min: 1000000

    UID Range Max: 2000000

2. isilab-1# isi auth ads list --verbose

                     Name: 

          Machine Account: ISILAB$

           Authentication: Yes

                   Status: online

           Primary Domain: 

                   Forest: 

                     Site: 

           NetBIOS Domain: 

                 Hostname: i

          Controller Time: 2015-02-03T15:31:35

       Cache Entry Expiry: 4H

         Node DC Affinity: -

 Node DC Affinity Timeout: -

          NSS Enumeration: No

              SFU Support: none

       Store SFU Mappings: No

        Ignore All Trusts: No

  Ignored Trusted Domains: -

  Include Trusted Domains: -

    Domain Offline Alerts: No

       LDAP Sign And Seal: No

             Lookup Users: Yes

   Lookup Normalize Users: Yes

            Allocate UIDs: No

  Lookup Normalize Groups: Yes

            Allocate GIDs: No

           Lookup Domains: -

            Lookup Groups: Yes

    Assume Default Domain: No

    Check Online Interval: 5m

 Machine Password Changes: Yes

Machine Password Lifespan: 1M

    Create Home Directory: No

  Home Directory Template: /ifs/home/%D/%U

              Login Shell: /bin/zsh

Thanks!

[Andrew Stack]

Hello,

Before this question can be answered it would be helpful to know if you have RFC 2307 enabled or if you prefer Unix Services for Windows installed on your Domain Controllers?  Also are you using any NIS, LDAP or group/password file for Unix user identity management?

Regards,

-- 

Andrew Stack

Sr. Storage Administrator

Genentech

Cell - 650.867.5524

--
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.

--

Andrew Stack

Sr. Storage Administrator

Genentech

Cell - 650.867.5524

[gtjones]

Andrew,

I'll answer this way because I'm not certain what you mean when you say is RFC2307 enabled. We use AD for Windows identity and LDAP for UNIX identity. We do not store GID/UID information in AD.

Greg

[Adam Fox]

On-disk identity is exactly that.  The owner and permissions of a file or directory that is actually written to disk.  While OneFS maps users between UNIX and Windows IDs, it only writes one set of permissions to disk, and if it needs the other, it does a mapping in-memory based on the on-disk identity.

Which identity is on disk?  Well, that depends on who wrote the file initially and then who set permissions later.  A Windows ACL will take precedence over UNIX POSIX bits as they are more descriptive.  So if you wrote the file from NFS with UNIX-style POSIX permissions, then the on-disk identity would be the UID/GID.  If you never change the permissions of that file from Windows to apply an ACL, then the user's Windows identity would remain UNIX-style and any Windows ID/permissions would be generated from the UID/GID and POSIX bits on an as-needed basis.  If you were to set an ACL on it via SMB (or if you wrote the file via SMB at file creation), then the WIndows SID, ACLs would be the on-disk identity and the UNIX UID/GID and POSIX permission bits would be created on the fly as needed.

Does this make sense?  Unlike VNX file which maintains two separate sets of owners/permissions on every file/directory on-disk, OneFS maintains one and generated the other if needed.  The goal is to maintain consistent access regardless of how a user accesses the file (not just NFS and SMB, but FTP, HTTP, HDFS, SWIFT, etc.).

Make sense?

-- Adam

---

From: gtjones <gtjo...@gmail.com>
To: isilon-u...@googlegroups.com
Sent: Tuesday, February 3, 2015 3:36 PM
Subject: Isilon-Users On-Disk Identity and UID GID Allocation

[Adam Fox]

On-disk identity is exactly that.  The owner and permissions of a file or directory that is actually written to disk.  While OneFS maps users between UNIX and Windows IDs, it only writes one set of permissions to disk, and if it needs the other, it does a mapping in-memory based on the on-disk identity.

Which identity is on disk?  Well, that depends on who wrote the file initially and then who set permissions later.  A Windows ACL will take precedence over UNIX POSIX bits as they are more descriptive.  So if you wrote the file from NFS with UNIX-style POSIX permissions, then the on-disk identity would be the UID/GID.  If you never change the permissions of that file from Windows to apply an ACL, then the user's Windows identity would remain UNIX-style and any Windows ID/permissions would be generated from the UID/GID and POSIX bits on an as-needed basis.  If you were to set an ACL on it via SMB (or if you wrote the file via SMB at file creation), then the WIndows SID, ACLs would be the on-disk identity and the UNIX UID/GID and POSIX permission bits would be created on the fly as needed.

Does this make sense?  Unlike VNX file which maintains two separate sets of owners/permissions on every file/directory on-disk, OneFS maintains one and generated the other if needed.  The goal is to maintain consistent access regardless of how a user accesses the file (not just NFS and SMB, but FTP, HTTP, HDFS, SWIFT, etc.).

Make sense?

-- Adam

---

From: gtjones <gtjo...@gmail.com>
To: isilon-u...@googlegroups.com
Sent: Tuesday, February 3, 2015 3:36 PM
Subject: Isilon-Users On-Disk Identity and UID GID Allocation

[gtjones]

Adam,

Thanks. I think this is coming together....

Let me restate it to see if I understand and forgive me if its redundant.

1. When a file is written from UNIX, the on-disk permissions are POSIX permission bits. If a Windows user does a properties view on that file, Isilon interprets the POSIX permission bits into synthetic ACLs.

2. When  a Windows user writes a file, Windows ACLs become the on-disk permission. If a UNIX client executes an ls on the file, the POSIX permission bits are interpreted from the ACL.

In both cases, what we say is on-disk is what's actually written. 

For example, when I do an ls form Isilon on this directory, I get the following:

drwxrwx--- +  2 XX\frank  unixadm  175 Feb  3 14:30 .

 OWNER: user:XX\frank

 GROUP: group:unixadm

 CONTROL:dacl_auto_inherited,sacl_auto_inherited,dacl_protected

 0: user:frank-ds allow dir_gen_read,dir_gen_execute,object_inherit,container_inherit

 1: user:XX\dataview allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit

 2: group:XX\groupA allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,delete_child,object_inherit,container_inherit

 3: group:Administrators allow dir_gen_all,object_inherit,container_inherit

The on-disk permissions is the ACL (ACEs 0-3) and the POSIX bits 770 are interpreted based on the ACL.

There's also the case of on-disk identity which I understand to be either a UID/SID or GID/SID that's written to disk. I can see my on-disk identity by running the isi auth mapping token command. When I see on-disk with my UID next to it, I assume this means that any time a permission is granted to me, it writes my identity to disk as a UID. If I had a SID there, it writes my SID to disk as my identity. So there's a translation for permissions and identity depending on what protocol you're using and your on-disk identity.

Executing the same ls as above without looking up names. This tells me that user frank has a UID of 22353 and based on that, his on-disk is his UID. The user dataview however has an on-disk of SID as demonstrated by the ACL.

drwxrwx--- +  2 22353  2001  221 Feb  4 10:11 .

 OWNER: user:22353

 GROUP: group:2001

 CONTROL:dacl_auto_inherited,sacl_auto_inherited,dacl_protected

 0: user:32674 allow dir_gen_read,dir_gen_execute,object_inherit,container_inherit

 1: SID:S-1-5-21-2077763542-2135228977-565468543-655438 allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit

 2: SID:S-1-5-21-2077763542-2135228977-565468543-194992 allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,delete_child,object_inherit,container_inherit

 3: SID:S-1-5-32-544 allow dir_gen_all,object_inherit,container_inherit

I hope I got this mostly right.

Thanks,

Greg