Start a Conversation

Unsolved

Closed

T

14 Posts

237

May 15th, 2023 10:00

Usermapper and Unix Everyone else

So have an issue with our our Unix admins, instead of fixing a problem, they want to continue to rum chmod and change permissions to 755/777 whenever someone can't access a Directory/File.  The problem is that in this zone has both Unix LDAP and Windows Active Directory authentication provider on a zone as it is shared between unix hosts and windows hosts.   The issue being that when everyone else is given permission, it is also giving domain users access via the mapper.   Thus opening the data up to pretty much everyone in the environment.   

I can not really find any good documentation or am not searching for the correct information, so any help would be appreciated and yes I know I can disable chmod, but in my environment that is not an option.  

 

14 Posts

May 16th, 2023 06:00

Let's try this again.  I have a directory structure shared out via a NFS export and a SMB share.   I have two different authentication providers on the zone (Unix LDAP and Windows Active Directory). The providers are independent of the other, only the user ids match, so I have a mapping rule setup that matches ID from each to create the local mapping token.    

My issues:  When a unix admin changes the permissions of a file from the unix side (chmod 775 or 777),  from the windows side the Domain Users group is added and now has either change or full access depending on the "everyone else" permission set from the unix side.    I am trying to determine how to squash the mapping. between "everyone else" and Domain users.   

Moderator

 • 

8.4K Posts

May 16th, 2023 06:00

Hi,

Thank you for your question. What are you looking for help with in the situation? This might help. https://dell.to/3BvHqIj

Let us know if you have any additional questions.

Moderator

 • 

8.4K Posts

May 16th, 2023 07:00

There might be something in here that is helpful. https://dell.to/3o49Upo It goes through all of the options for mapping.

May 16th, 2023 08:00

> Thus opening the data up to pretty much everyone in the environment.

That's what chmod 777 is supposed to accomplish... 

I assume your situation is that there are much less Unix users than Windows users? So you wish that 777 affects exactly those few Unix users, but not the "Windows only"users.

Let's keep in mind that the mapping rule is symmetric and has no "idea" wether both sides fully match across the board, or wether one side is only a smaller subset of the other. So "everyone" can implicitly mean very different sets of users. Which means you can't simply, with a single chmod 777, achieve what you have in mind.

A solution might include creating a special group for the Unix users and a corresponding mapped group in AD, and then: chgrp unixers file; chmod 770 file. Probably wrapped together in a tiny script...

 

14 Posts

May 17th, 2023 11:00

Peter, I am not trying to chmod mod anything, I am trying to prevent it from being a security risk.

You are correct the 775/777 is doing exactly what is supposed to do.... but in a Unix host everyone else is only everyone else that can access that host.   With the syntactic ACLS from Powerscale, when the chmod 775 is run on a directory\file I am seeing everyone allow XXXX being added to the ACL.  No big deal, but since this is shared out between NFS and SMB shares and the multi authentication providers everyone is mapped to the AD group Domain users.  

That mapping is what I am trying to remove.  I have attempted to educate our admins not to run chmod and to request permissions changes from our security group to correct access issues, but it doesn't work, they do it anyway.   So, I am looking for a way to at least keep the data from being made to available to every member of our Active directory. 

May 17th, 2023 13:00

I can't see an obvious way to change how the synthetic ACLs are generated (on the fly). Things are convoluted -- have you seen this whitepaper on OneFS ACLs ? Maybe some clever combination of settings will do it, or give rise to some acceptable alternate solution, but frankly I doubt it.

No Events found!

Top