Reset access rights (DACL) after moving a file

[Ether]

Lately, I've been taking advantage of NTFS's security features and I found that Salamader behaves contra-productively when moving files. It only moves the file, but it does not reset the access rights on the file and the new rights (inherited from the new containing directory) don't go into effect. Explorer seems to do it right.

I'm attaching a Process Monitor dump which shows Salamander moving the file to a new directory and back and then Explorer doing the same. I think there's a useful hint as to what API Salamander should be calling. Regarding directories - according to my tests and to what Explorer and icacls do when changing access rights, when moving directories the security information must be reset also on everything inside it, recursively.

Code: Select all

11:40:21,0826964	salamand.exe	4516	SetRenameInformationFile	D:\users\ether\testfile	SUCCESS	ReplaceIfExists: False, FileName: D:\users\ether\temporary\dropbox\testfile
11:40:33,6525376	salamand.exe	4516	SetRenameInformationFile	D:\users\ether\temporary\dropbox\testfile	SUCCESS	ReplaceIfExists: False, FileName: D:\users\ether\testfile
11:40:42,6317710	explorer.exe	5908	SetRenameInformationFile	D:\users\ether\testfile	SUCCESS	ReplaceIfExists: False, FileName: D:\users\ether\temporary\dropbox\testfile
11:40:42,6346747	explorer.exe	5908	SetSecurityFile	D:\users\ether\temporary\dropbox\testfile	SUCCESS	Information: DACL, DACL Unprotected
11:40:46,0793524	explorer.exe	5908	SetRenameInformationFile	D:\users\ether\temporary\dropbox\testfile	SUCCESS	ReplaceIfExists: False, FileName: D:\users\ether\testfile
11:40:46,0823213	explorer.exe	5908	SetSecurityFile	D:\users\ether\testfile	SUCCESS	Information: DACL, DACL Unprotected

[therube]

What are the implications of doing it the Explorer way vs. doing it the (current) Salamander way?

I am contra-security, if you will.

I may use multiple User accounts (for differing purposes), but I do not want to be limited or affected in actions I take on a system based upon the logged in User. (I generally do not use or keep data in any special folders, instead using locations & structures of my choosing. So if a "special" folder is "off limits", I generally don't care.) I want each User to be able to access most anything they want, without jumping through hoops. (And as NTFS Permissions has always baffled me, I try to stay away from make changes in that [to me] morass.)

[Ether]

What are the implications of doing it the Explorer way vs. doing it the (current) Salamander way?

Actually, the results of Explorer's way are more intuitive and also consistent.

If you move a file from a location (which may have restrictive ACL on it) to another location (with a more permissive ACL), you expect that file to be now accesible according to the new location. With the current state of Salamander, you get mixed results depending on the operation and application:

• copying with Explorer - OK (a new file is created with the correct inherited ACL)
• copying with Salamander - OK (a new file is created with the correct inherited ACL)
• moving with Explorer - OK (the ACL is reset after moving to the new location)
• moving with Salamander - the old ACL is retained and not reset

OT BTW You may want to update your signature.

[therube]

That seems to make sense.
Thanks.


> OT BTW You may want to update your signature.

Yeah, I know, have known.
(It will always be "Servant" to me .)

[omega]

(It will always be "Servant" to me .)

You are not the only one

[Ether]

Yeah, I know, have known.
(It will always be "Servant" to me .)

Yeah, I wasn't objecting to that. I just noticed you have had v2.53b there.

[Petr Solin]

Thanks for analysing this problem. We use API call MoveFile for this operation, I did not expected any other action is needed from our side. I have added this problem to my to-do list and will solve it after preparing x64 version of Salamander.

[Ether]

There's a relevant article on the Old New Thing blog.