Page 1 of 1
Permissions ineffective
Posted: Fri Jul 21, 2006 6:34 pm
by rvjr
Hi,
i've got a strange problem: if i have a file with accessrights 'everyone=read&execute' and i add an entry with full access for my current user, and then remove the entry for my user, i can still modify and delete the file... why that? the windows permissions dialog then just shows 'everyone=read&execute' and nothing more...
ciao,
Rainer.
Posted: Mon Nov 27, 2006 8:45 am
by madshi
That sounds very strange. Can you reproduce this problem? Can you still delete the file after a reboot?
Posted: Mon Nov 27, 2006 2:24 pm
by rvjr
hmm... I haven't tried this yet, I'm going to check it this afternoon.
Posted: Mon Nov 27, 2006 5:19 pm
by rvjr
Well, at the moment I am not able to reproduce the behaviour. But I encountered this problem several times. In the meantime, I had skipped using my ACL-Lock-Tool, but I'm going to use it again from now on, so I will be able to check if a reboot solves this...
Thanks for your reply,
ciao,
Rainer
Posted: Sun Dec 03, 2006 5:56 pm
by rvjr
Hi!
This time I could reproduce the behaviour again: I changed the permissions of a directory (Let's call it root directory) and its subfolders and files from Everyone=Read+Execute to Everyone=Read+Execute and Me=FullControl. After that, I opened a programming project within this root directory and coded a while. Then I closed my IDE and changed the permissions back (for all objects within the root, and the root itself). When using the file properties dialog, the permissions only showed Everyone=Read+Execute for the root directory and all of the subfolders and files, but I was still able to rename files and folders within the root. After a reboot, I could not rename the files and folders anymore.
Is there any explication for this?
Should I post some code of my application?
caio,
Rainer.
Posted: Mon Dec 04, 2006 7:24 am
by madshi
That's really strange. I never heard about such a problem yet. The fact that a reboot helps shows that what madSecurity does seems to be correct. Have you tried logging off and on again? Maybe that helps, too?
Which OS and which file system is this?
Posted: Mon Dec 04, 2006 1:01 pm
by rvjr
Yes, you're right, this may not be a problem of the madsecurity lib. next time I experience the problem, I'll try to logoff and on again. I'm currently using WindowsXP SP2 with NTFS volumes.
Posted: Mon Dec 04, 2006 1:17 pm
by rvjr
But I think I'm doing something wrong with the parameters of the permission entries, because I had to experiment a lot with these to get it to work. Perhaps you can take a look at the two functions used to set the permissions...
The following procedure add's the 'full control' permission to the object specified by O (O is a string, identifying a file or folder) after removing all previous permissions for the specified user. There is an outer procedure (around this one) that loops through folders, subfolders and files and calls AddPermission for every single file, folder and subfolder.
Code: Select all
procedure AddPermission;
begin
with FileSecurity (O) do begin
if not Owner.IsEqual (CurrentUser) then begin
Owner := CurrentUser;
end;
DAcl.DeleteItems (Account (fAccountName));
DAcl.NewItem (Account (fAccountName), $D0000000, atAllowed, [afObjectInherit, afContainerInherit]);
DAcl.Flush;
if not Success then begin
Err := true;
end;
end;
end;
The same with the function that removes permissions:
Code: Select all
procedure RemovePermission;
begin
with FileSecurity (O) do begin
if not Owner.IsEqual (CurrentUser) then begin
Owner := CurrentUser;
end;
DAcl.DeleteItems (Account (fAccountName));
DAcl.Flush;
if not Success then begin
Err := true;
end;
end;
end;
Also, on creation of my program, I call the EnableAllPriviledges function I found somewhere in this forum:
Code: Select all
procedure EnableAllPrivileges;
type TTokenPrivileges = record
PrivilegeCount: DWord;
Privileges: array [0..MaxInt shr 4 - 1] of TLUIDAndAttributes;
end;
var c1, c2: dword;
i1: integer;
ptp: ^TTokenPrivileges;
backup, restore: int64;
begin
if OpenProcessToken (windows.GetCurrentProcess, TOKEN_ADJUST_PRIVILEGES or TOKEN_QUERY, c1) then
try
c2 := 0;
GetTokenInformation (c1, TokenPrivileges, nil, 0, c2);
if c2 <> 0 then begin
ptp := pointer (LocalAlloc (LPTR, c2 * 2));
if GetTokenInformation (c1, TokenPrivileges, ptp, c2 * 2, c2) then begin
// enabling backup/restore privileges breaks Explorer's Samba support
if not LookupPrivilegeValue (nil, pchar ('SeBackupPrivilege'), backup) then backup := 0;
if not LookupPrivilegeValue (nil, pchar ('SeRestorePrivilege'), restore) then restore := 0;
for i1 := 0 to integer (ptp^.PrivilegeCount) - 1 do
if (ptp^.Privileges [i1].Luid <> backup ) and
(ptp^.Privileges [i1].Luid <> restore) then
ptp^.Privileges [i1].Attributes := ptp^.Privileges [i1].Attributes or SE_PRIVILEGE_ENABLED;
AdjustTokenPrivileges (c1, false, PTokenPrivileges(ptp)^, c2, PTokenPrivileges (nil)^, cardinal (pointer (nil)^));
end;
LocalFree (DWord (ptp));
end;
finally
CloseHandle (c1)
end;
end;
Any ideas?
Posted: Mon Dec 04, 2006 1:24 pm
by madshi
You need to make yourself clear that e.g. "DAcl" is a function which reads out the DACL and creates a new IAcl interface and returns it. So please use "with DAcl" or call it once and put it into a local variable. Avoid calling the same method multiple times. This saves performance and *might* improve the behaviour as well.
Posted: Mon Dec 04, 2006 4:34 pm
by rvjr
Oh, okay, that's right! I've changed this into a with-block. I'll let you know if the problem still exists...
thanks