ntsec change needed to read one of my partitions

Corinna Vinschen vinschen@redhat.com
Tue Nov 25 10:23:00 GMT 2003


On Tue, Nov 25, 2003 at 12:23:23AM -0500, Pierre A. Humblet wrote:
> At 11:28 PM 11/24/2003 -0500, Christopher Faylor wrote:
> >On Mon, Nov 24, 2003 at 11:06:16PM -0500, Pierre A. Humblet wrote:
> >>>FWIW, the size returned by read_sd was 4144 so bumping things up to
> >>>8192 was probably overkill.
> >>
> >>4144 IS very strange, way high. 

I first observed weird sizes on NT4 already.  See my comment at the
beginning of get_nt_attribute().  The information in the SD didn't
seem to reflect the number of ACEs in the DACL but...

> >>What does cacls report?
> >
> >  k:\ BUILTIN\Administrators:(OI)(CI)F 
> >      NT AUTHORITY\SYSTEM:(OI)(CI)F 
> >      CREATOR OWNER:(OI)(CI)(IO)F 
> >      BUILTIN\Users:(OI)(CI)R 
> >      BUILTIN\Users:(CI)(special access:)
> >			FILE_APPEND_DATA
> >   
> >      BUILTIN\Users:(CI)(IO)(special access:)
> >			    FILE_WRITE_DATA
> >   
> >      Everyone:R 
> 
> That's 7 ACE's, each with a short SID. Ballpark size
> should be < 200 bytes. Something weird is going on.

...what about the SACL?  I doubt that it's actually 4K, though.

> Also      CREATOR OWNER:(OI)(CI)(IO)F 
> doesn't match   default:user::---
> We may be forgetting flags such as GENERIC_XYZ

Hmm, I'm having basically the same entries as above (plus some
additional SYNCHRONIZE bits) and my creator_owner entry is identical:

  CREATOR OWNER:(OI)(CI)(IO)F

But getfacl correctly prints

  default:user::rwx

> It surely would be interesting to dump the sd_buf
> from gdb. I don't doubt that Corinna would look forward
> to decode all 4144 bytes.

You're kidding.  How should one know what the bytes after the regular
length are?  It would be interesting, though, to get the ace->Mask entry
of the creator owner ACE. 

Chris, could you apply the below patch and send the created debug
output to this list?  For instance, the above creator owner entry looks
like this on my system:

24   12756 [main] getfacl 1884 cygpsid::debug_print: SID S-1-3-0
20   12776 [main] getfacl 1884 getacl: Type: 0, Flags: B, Mask: 1F01FF

> I vaguely recall seeing a strange sentence on MSDN, to the
> effect that extra info can be hidden after the SID in an ACE.
> I wonder if something like that is going on, or if there is
> just a lot of garbage in the tail of the DACL.

That would be good to know.  I didn't find that in MSDN, unfortunately.
Perhaps it makes sense to search the microsoft newsgroups.

> The max size of an ACL is 64k, and the SD is perhaps a 100
> more. Should we just bite the bullet and go there?

We could also use the GetFileSecurity() call to determine the needed
buffer size as we already do with GetTokenInformation().  It's just that
we have to change read_sd to return an allocated buffer then, which we
must not forget to free in the calling function.  Perhaps we should create
a sort of SD wrapper class which free's the buffer in the destructor.

Corinna

Index: sec_acl.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/sec_acl.cc,v
retrieving revision 1.32
diff -u -p -r1.32 sec_acl.cc
--- sec_acl.cc	25 Sep 2003 00:37:17 -0000	1.32
+++ sec_acl.cc	25 Nov 2003 10:20:24 -0000
@@ -319,6 +319,7 @@ getacl (const char *file, DWORD attr, in
       lacl[pos].a_perm = S_IROTH | S_IWOTH | S_IXOTH;
   else
     {
+      debug_printf ("AceCount: %d", acl->AceCount);
       for (i = 0; i < acl->AceCount; ++i)
 	{
 	  ACCESS_ALLOWED_ACE *ace;
@@ -327,6 +328,9 @@ getacl (const char *file, DWORD attr, in
 	    continue;
 
 	  cygpsid ace_sid ((PSID) &ace->SidStart);
+	  ace_sid.debug_print ("SID");
+	  debug_printf ("Type: %x, Flags: %x, Mask: %x",
+	  		ace->Header.AceType, ace->Header.AceFlags, ace->Mask);
 	  int id;
 	  int type = 0;
 
-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.



More information about the Cygwin-developers mailing list