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?

[Jeremy Allison]

On Mon, Apr 16, 2012 at 09:26:26PM -0700, Richard Sharpe wrote:
> 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.

We should probably test (or just ask dochelp if you're feeling
lazy :-).

> >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.

What UNIX filesystems do we have that allow 64k worth of EA's ?

Jeremy.