Permissions ineffective

delphi package - easy access to security apis

Permissions ineffective

Postby rvjr » Fri Jul 21, 2006 6:34 pm

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.
rvjr
 
Posts: 7
Joined: Fri Jul 21, 2006 6:30 pm

Postby madshi » Mon Nov 27, 2006 8:45 am

That sounds very strange. Can you reproduce this problem? Can you still delete the file after a reboot?
madshi
Site Admin
 
Posts: 9827
Joined: Sun Mar 21, 2004 5:25 pm

Postby rvjr » Mon Nov 27, 2006 2:24 pm

hmm... I haven't tried this yet, I'm going to check it this afternoon.
rvjr
 
Posts: 7
Joined: Fri Jul 21, 2006 6:30 pm

Postby rvjr » Mon Nov 27, 2006 5:19 pm

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
rvjr
 
Posts: 7
Joined: Fri Jul 21, 2006 6:30 pm

Postby rvjr » Sun Dec 03, 2006 5:56 pm

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.
rvjr
 
Posts: 7
Joined: Fri Jul 21, 2006 6:30 pm

Postby madshi » Mon Dec 04, 2006 7:24 am

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?
madshi
Site Admin
 
Posts: 9827
Joined: Sun Mar 21, 2004 5:25 pm

Postby rvjr » Mon Dec 04, 2006 1:01 pm

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.
rvjr
 
Posts: 7
Joined: Fri Jul 21, 2006 6:30 pm

Postby rvjr » Mon Dec 04, 2006 1:17 pm

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?
rvjr
 
Posts: 7
Joined: Fri Jul 21, 2006 6:30 pm

Postby madshi » Mon Dec 04, 2006 1:24 pm

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.
madshi
Site Admin
 
Posts: 9827
Joined: Sun Mar 21, 2004 5:25 pm

Postby rvjr » Mon Dec 04, 2006 4:34 pm

Oh, okay, that's right! I've changed this into a with-block. I'll let you know if the problem still exists...

thanks
rvjr
 
Posts: 7
Joined: Fri Jul 21, 2006 6:30 pm


Return to madSecurity

Who is online

Users browsing this forum: No registered users and 2 guests

cron