Preventing folder move (/deletion) on system using local authentication...?

[jerem...@it4vfx.com]

I manage an Isilon (OneFS Version: 7.0.2.9 with the SMB rollup) that was pulled out of Active Directory (in a mostly Windows environment) as a troubleshooting step and even though it didn't help the system then ended up deep in production with all users connecting to it via a logon mapping script with the root user and password specified.  (Deafening sound of facepalming across the group...)

And we routinely have problems where users will drag one folder into another (yay, Wacom tablets!), that move happens instantly but since the network is still writing to the previous location merging the files back is a PITA that takes a while which really screws up things until finished.  

So I read up on the best way to prevent this, and the consensus seems to be creating a file in the root of each directory you don't want move/deletable with a space as the first character of the name (so it's processed first) and set so users don't have write/delete access.  

Obviously this won't work with the current user mapping so I added a new local user.  

And I created the file.

And I tried changing the permissions through Isilon's web interface and through the command line.  

And it seems to ignore me either way...  

isilon01-1# ls -l

total 26

-rwxrwxrwx +  1 root  wheel  67 Feb  5 12:18  lockdown.txt

isilon01-1# chmod 744 " lockdown.txt"

isilon01-1# ls -l

total 26

-rwxrwxrwx +  1 root  wheel  67 Feb  5 12:18  lockdown.txt

Any comments so far?  Better way to do what I'm trying to accomplish?  

If not, why is it ignoring me?  Related to the Protocols|ACLs page?

chmod on files with existing ACLs:

which is currently: Ignore operation if file has an existing ACL

What counts as an 'existing' ACL?  New file... default counts as existing...?  

What are the potential impacts of changing to:

Remove the existing ACL and create an ACL equivalent to the UNIX permissions

or is another setting more recommended?  

Any other settings that would be needed to accomplish what I'm trying?  

[Peter Serocka]

-rwxrwxrwx +  1 root  wheel  67 Feb  5 12:18  lockdown.txt

The "+" indicates that and ACL has been set for this

file, and that the shown UNIX permission bits

cannot fully reflect the actual permissions.

To see the full ACL, use ls -le

Next, set the permissions on your lockdown file

from a Window client in the way that serves your needs 

(prohibit writing or something alike, test it right

on the Windows client. I didn't fully get why

a lockdown file should prevent the directory

from being moved -- or is is just the "first entry",

that accidentally gets picked and moved by 

Wacom tablet users?)

Then go back to the Isilon and check (ls -le)

how the ACL has been changed.

Supposed you want to apply the same

ACL change to other (all) directories

right on the Isilon, use chmod +a ...

to do that. Check man chmod for syntax details.

Or you may use the Set-Acl cmdlet with PowerShell on Windows...

Hope this helps as a starting point

-- Peter

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

Peter Serocka

CAS-MPG Partner Institute for Computational Biology (PICB)

Shanghai Institutes for Biological Sciences (SIBS)

Chinese Academy of Sciences (CAS)

320 Yue Yang Rd, Shanghai 200031, China

pser...@picb.ac.cn

[jerem...@it4vfx.com]

Thanks Pete, I'd figured that the 'setting it from Windows' route was closed to us because of the removal from AD, but will try.  

It's not the lockdown file, it's the fact that the space at the front of any file's name " lockdown.txt" combined with not being able to delete that file will cause a move to fail before it gets to anything else.  Don't want to change permissions wholesale to directories/etc, just want to prevent accidental move/deletions but still have people able to create/rename when they need to.  

[Neproshennie]

Jeremy,

You cannot prevent deletion of files while still allowing renaming due to how the NTFS permission scheme is designed. Renaming is creating a new filesystem pointer and deleting the old so if you deny deletes, you will deny renames/moves. You can enable auditing (SACL) to track moves/deletes as well as utilize snapshots if you want a contingency plan. If users frequently accidentally move/rename/delete files then their usage should be taken into consideration to prevent the problem at the source.

--Jamie Ivanov

[Jeremy Lang]

Pete, I tried the from-windows route, is denied by the (...)settings on our Isilon.  

Jamie, I don't want users able to rename top-level folders either.  

It's just that the fixes that I've heard about are stymied by the root access in place and I haven't found any workaround yet that I'm comfortable in production.  

______________
Jeremy M. Lang
it4vfx
¯¯¯¯¯¯¯¯¯¯¯¯¯¯

--
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/1aPcOCPmG-4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to isilon-user-gr...@googlegroups.com.

[Neproshennie]

Jeremy,

Do the users have "std_required" or "modify" within the ACE? It looks like "dir_gen_all" doesn't contain "std_write_dac" which is contained in the other two groups. I'm referring to the man page for "chmod" via my iPhone so I may have overlooked something while squinting my aging eyes.

--Jamie Ivanov

[Chris Andrus]

There seem to be some good Isilon fixes below, but here's something that may fix the underlying problem:

We run into the same, "Whoops, I just moved a directory" issue here.  Part of our solution involved updating our Windows' clients drag-and-drop distance.  By default, you only have to move a directory/file 4 pixels, and it registers as a "move".  This is pretty small considering the resolution of today's monitors.  So we changed that to 50, and we've had no more accidental moves.

The registry values you'd want to change are "DragHeight" and "DragWidth" in HKEY_CURRENT_USER\Control Panel\Desktop 

[Jerry Uanino]

Genius. +1000 points for whoever found that one.

--