Fwd: [REG : 112040380892433]: Is there any requirement when handling an NT_TRANSACT_SET_SECURITY_DESCRIPTOR to store the DACL exactly as presented on the wire?

[Richard Sharpe]

On Mon, Apr 16, 2012 at 9:56 AM, Jeremy Allison <jra at samba.org> wrote:
> On Mon, Apr 16, 2012 at 09:54:42AM -0700, Jeremy Allison wrote:
>> On Mon, Apr 16, 2012 at 12:41:58PM -0400, Scott Lovenberg wrote:
>> > On 4/16/2012 12:38 PM, Jeremy Allison wrote:
>> > >
>> > >Ouch. That's really bad - and is essentially an additional
>> > >meta-data store on Windows people can hide *anything* inside.
>> > >
>> > >Jeremy
>> > Yeah, and we already have Alternative Data Streams for that! :D
>>
>> Another problem with us trying to emulate this is that the
>> space for SD's is limited by the available size in Linux/UNIX
>> xattrs, so trying to store an unmodified DACL will stress
>> this size even more :-(.
>
> It would also be useful to write test programs against Windows
> to determine the maximum size of stored SD's on NTFS. This also
> might be different on ReFS.

NetApp has such an application. They seem to think that 64kiB is the
max size of an SD, and I have heard that number before as well.

> IMHO this is something only broken applications would depend

>From the point of view of Samba, while we could perhaps consider an
option to allow the input buffer to be stored as is, it does raise the
issue of what to do when we retrieve the SD and try to interpret it
for security checks but cannot make any sense of the stored SD.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)