[spam-high] Re: [PATCH 3/7] advapi: Implement GetNamedSecurityInfoW on top of GetSecurityInfo (try 3).

[Charles Davis]

On Nov 4, 2012, at 10:11 PM, Erich E. Hoover wrote:

> If the object is resolvable with CreateFile then it doesn't matter if
> it's a file, directory, named pipe, or some other miscellaneous thing.
True, and of course by "file" I meant "any object that can act like a file," which includes directories, pipes, devices, etc.

I will add that the 'type' parameter also affects how the path that gets passed in is parsed. But you're right, CreateFile() will fail anyway for those kinds of paths, so I guess it's OK to ignore the 'type' for now.
> I templated part 2 after how GetSecurityInfo works (it also ignores
> the SE_OBJECT_TYPE), I'm not even sure what type of object you'd call
> the function with where it might matter.
I can name at least four: registry keys (HKEY), services (SC_HANDLE), window stations (HWINSTA), and desktops (HDESK). On native, all those types of objects are protected with ACLs, and all those types have unique functions for manipulating them. But you don't have to worry about that for now; just supporting file-like objects is fine right now, especially since Wine only supports one user per prefix right now, so objects that exist in the file-system are the only ones where we have to worry about other users. (Besides, Wine probably doesn't even support multiple window station and desktop objects anyway...)

Sorry for the noise.

Chip

> 
> Erich
> 
> On Sun, Nov 4, 2012 at 3:15 PM, Charles Davis <cdavis5x at gmail.com> wrote:
>> 
>> On Nov 4, 2012, at 1:30 AM, Erich E. Hoover wrote:
>> 
>>> This patch implements GetNamedSecurityInfoW on top of the more
>>> fundamental GetSecurityInfo function, permitting the return of more
>>> accurate ownership information for files.  PlayReady uses this
>>> information to determine if its files have the appropriate
>>> permissions, without the correct permissions it will attempt to recopy
>>> the individualization file (and fail).  Additionally, this patch adds
>>> tests for retrieving the ACL information set on files.
>>> 
>>> This version fixes some problems in the tests on older Windows
>>> versions, sorry I didn't catch that earlier.  It now also fixes a
>>> mistake I made between testing try 2 and pushing it out :/
>> 
>>> +    hfile = CreateFileW( name, access, FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
>>> +                         NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0 );
>> Only works on files right now, huh? You might then want to check to make sure the caller says it's a file by comparing the 'type' against SE_FILE_OBJECT, and return ERROR_CALL_NOT_IMPLEMENTED if they didn't. After all, part of the point of that parameter is to tell you which function you need to call to open the object in the first place :). (Same for patch 2.)
>> 
>> Chip
>>