Re: [PATCH 3/7] advapi: Implement GetNamedSecurityInfoW on top of GetSecurityInfo (try 3).
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
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. 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.
Erich
On Sun, Nov 4, 2012 at 3:15 PM, Charles Davis cdavis5x@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
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@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
On Mon, Nov 5, 2012 at 12:41 PM, Charles Davis cdavis5x@gmail.com wrote:
... 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.
Quite alright, you make good points. Since I just defended my dissertation this morning, I can now focus on this more intensely. I honestly should have thought of the registry keys at the very least, but for some reason that thought escaped me. Previously GetNamedSecurityInfo just blanket returned world access rights which, to me, is really masquerading as a semi-stub and hiding a host of unsupported features. At this point it would probably be better to break a few apps by failing utterly than silently succeed, that way we can determine what we need to implement.
Erich
-
Charles Davis -
Erich E. Hoover