full deny, yet limited user can still rename files in g:\bin

[nova2]

ok, i got it working.

denying delete perms on the directory via 'this dir, and its files' worked.

just deny inheritance for the files that you will allow to be renamed inside the dir.

thanks all.


------------------- (old)
ideas?

confirmed the limited user ("user group", only) cannot read the file, nor "read only protect" the file. user doesn't own the file.

no perms are being inherited on this exe file I am testing with.

why aren't the denying of all perms completely dominating these exe files in g:\bin?

I even tried specifying the username, and not the group name.
same result. the domain "box8" is correct.

created g:\test, to see if same like g:\bin.
same result.

making the file read only doesn't help, even tho the user cannot remove readonly flag.

if I deny "list folder" for g:\, renaming deny.x errors with G:\ not accessible, access denied (cool !)

however, other writable files on g:\ are affected, as in, they can't be moved, deleted, renamed, copied, but can be written to.
this isn't acceptable.

what happens when you rename a file on "NT":
" In addition, when you rename a file on NT, the rename operation opens the source file for delete access (a rename operation, after all is a creation of a new file in the target directory and a deletion of the source file)."
http://blogs.msdn.com/larryosterman/archive/2004/05/13/131263.aspx

 

[nova2]

bump

 

[nova2]

bump

 

[nova2]

ok, i switched to a different machine, (significantly different hardware, same os) and it also happens on this seperate box.

any permission gurus out there?

 

[GeekDrew]

Give us the complete folder structure for what you're talking about.

Are you setting permissions on g:\bin, and the file you're talking about is g:\bin\someprogram.exe?

 

[nova2]

g:\bin filled with files, no sub-dirs.

new files in g:\bin will inherit some permissions from parent.

to the point, even when I remove the inherited perms, and deny all perms for bin\app.exe, app.exe can still be renamed/deleted.

what could cause this? or is there no way around this?
denying all perms should be absolutely dominating this little limited user, non file owner.

 

[Nothinman]

to the point, even when I remove the inherited perms, and deny all perms for bin\app.exe, app.exe can still be renamed/deleted.

Did you check the permissions on the directory? Renaming a file is a directory operation, so is restricted by the permissions on the directory not the file. At least I think so, I know it works that way in unix but I'm sketchy on the Windows rules right now.

And you shouldn't be using denies anyway, you should just remove all rights from the files and add those that you want to have rights. Not having rights to a file is an explicity deny.

 

[GeekDrew]

Originally posted by: Nothinman

to the point, even when I remove the inherited perms, and deny all perms for bin\app.exe, app.exe can still be renamed/deleted.

Did you check the permissions on the directory? Renaming a file is a directory operation, so is restricted by the permissions on the directory not the file. At least I think so, I know it works that way in unix but I'm sketchy on the Windows rules right now.

And you shouldn't be using denies anyway, you should just remove all rights from the files and add those that you want to have rights. Not having rights to a file is an explicity deny.

I also believe that's the way it works, but I'm much more familiar with NetWare permissions than I am with Windows, so I was going to go verify that... just haven't had time. I'm sure you're right, though.

 

[Rilex]

Renaming a file is a directory operation,

Renaming a file is a file operation. It involves deleting the file and creating a new one (though directory permissions would take care of that, as well).

Not having rights to a file is an explicity deny.

An explicit deny is explicitedly placing a deny entry on a file. Not having rights is just not having rights.

 

[GeekDrew]

Originally posted by: Rilex

Renaming a file is a directory operation,

Renaming a file is a file operation. It involves deleting the file and creating a new one (though directory permissions would take care of that, as well).

Renaming a file is a file operation, but it does require specific directory permissions, does it not?

 

[nova2]

ok, i got it working.

denying delete perms on the directory via 'this dir, and its files' worked.

just deny inheritance for the files that you will allow to be renamed inside the dir.

thanks all.

 

[Nothinman]

Renaming a file is a file operation. It involves deleting the file and creating a new one (though directory permissions would take care of that, as well).

No, renaming a file should not delete the first one, it should just change the name associated with that inode/MFT entry. At least that's the way it _should_ work, I wouldn't be surprised if MS implemented it in a non-atomic fashion.

An explicit deny is explicitedly placing a deny entry on a file. Not having rights is just not having rights.

And for all practical purposes not having rights to a file is essentially equivalent to an explicit deny.

 

[GeekDrew]

Originally posted by: Nothinman

An explicit deny is explicitedly placing a deny entry on a file. Not having rights is just not having rights.

And for all practical purposes not having rights to a file is essentially equivalent to an explicit deny.

aka an implicit deny, if you didn't explicitly define it.