Merge pull request #210421 from normesta/gen2

Fixing something

Author: prmerger-automator[bot]

articles/storage/blobs/data-lake-storage-access-control.md

@@ -238,36 +238,18 @@ When a new file or directory is created under an existing directory, the default
 
 ### umask
 
-When creating a file or directory, umask is used to modify how the default ACLs are set on the child item. umask is a 9-bit value on parent directories that contains an RWX value for **owning user**, **owning group**, and **other**.
+When creating a default ACL, the umask is applied to the access ACL to determine the initial permissions of a default ACL. If a default ACL is defined on the parent directory, the umask is effectively ignored and the default ACL of the parent directory is used to define these initial values instead.  
+
+The umask is a 9-bit value on parent directories that contains an RWX value for **owning user**, **owning group**, and **other**.
 
 The umask for Azure Data Lake Storage Gen2 a constant value that is set to 007. This value translates to:
 
 | umask component     | Numeric form | Short form | Meaning |
 |---------------------|--------------|------------|---------|
-| umask.owning_user   |    0         |   `---`      | For owning user, copy the parent's default ACL to the child's access ACL |
-| umask.owning_group  |    0         |   `---`      | For owning group, copy the parent's default ACL to the child's access ACL |
+| umask.owning_user   |    0         |   `---`      | For owning user, copy the parent's access ACL to the child's default ACL |
+| umask.owning_group  |    0         |   `---`      | For owning group, copy the parent's access ACL to the child's default ACL |
 | umask.other         |    7         |   `RWX`      | For other, remove all permissions on the child's access ACL |
 
-The umask value used by Azure Data Lake Storage Gen2 effectively means that the value for **other** is never transmitted by default on new children, unless a default ACL is defined on the parent directory. In that case, the umask is effectively ignored and the permissions defined by the default ACL are applied to the child item.
-
-The following pseudocode shows how the umask is applied when creating the ACLs for a child item.
-
-```console
-def set_default_acls_for_new_child(parent, child):
-    child.acls = []
-    for entry in parent.acls :
-        new_entry = None
-        if (entry.type == OWNING_USER) :
-            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
-        elif (entry.type == OWNING_GROUP) :
-            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
-        elif (entry.type == OTHER) :
-            new_entry = entry.clone(perms = entry.perms & (~umask.other))
-        else :
-            new_entry = entry.clone(perms = entry.perms )
-        child_acls.add( new_entry )
-```
-
 ## FAQ
 
 ### Do I have to enable support for ACLs?
@@ -329,7 +311,7 @@ A GUID is shown if the entry represents a user and that user doesn't exist in Az
 ### How do I set ACLs correctly for a service principal?
 
 When you define ACLs for service principals, it's important to use the Object ID (OID) of the *service principal* for the app registration that you created. It's important to note that registered apps have a separate service principal in the specific Azure AD tenant. Registered apps have an OID that's visible in the Azure portal, but the *service principal* has another (different) OID.
-
+Article	
 To get the OID for the service principal that corresponds to an app registration, you can use the `az ad sp show` command. Specify the Application ID as the parameter. Here's an example on obtaining the OID for the service principal that corresponds to an app registration with App ID = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. Run the following command in the Azure CLI:
 
 ```azurecli