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?

[simo]

On Tue, 2012-04-17 at 09:16 -0700, Jeremy Allison wrote: 
> 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 ?

XFS IIRC

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>