Grumble. By not passing an FSP into READDIR etc we make it harder for OEMs to avoid modifying Samba

[Richard Sharpe]

On Mon, Oct 7, 2013 at 3:45 PM, Jeremy Allison <jra at samba.org> wrote:
> On Mon, Oct 07, 2013 at 03:15:39PM -0700, Richard Sharpe wrote:
>> On Mon, Oct 7, 2013 at 10:49 AM, Jeremy Allison <jra at samba.org> wrote:
>> > On Mon, Oct 07, 2013 at 10:41:51AM -0700, Richard Sharpe wrote:
>> >> Hi folks,
>> >>
>> >> We want to play games in READDIR that would have been enabled at
>> >> OPENDIR/FDOPENDIR time by noticing certain things and adding an FSP
>> >> Extension that allowed us to easily detect that we are in the
>> >> situation we are interested in and can then play the games we want to
>> >> play.
>> >>
>> >> Unfortunately, there is no FSP passed into READDIR ... sigh. Not even in Master.
>> >
>> > There is a way to get there from here :-). It's ugly, but doable.
>> >
>> > vfs_readdir() takes an SMB_STRUCT_DIR *, which should have been returned
>> > from vfs_fdopendir(). vfs_fdopendir *does* take a fsp, and so you can
>> > add an associative cache inside opendir that links fsp's to SMB_STRUCT_DIR *
>> > pointers. The inside vfs_readdir() do the fsp lookup.
>>
>> That is kind of ugly :-(
>
> I already said that. Works though :-).
>
>> Could we pass the struct dptr_struct down one more later?
>
> We'd have to make it a public struct. Might work. Let's
> see the code :-).

I failed to mention that I completely understand the reason for the
lack of an FSP. Basically, because of the SMB1 code paths there are
too many cases where we do not get an FSP.

Let me see if I can come up with something. I am thinking along the
lines of embedding a void pointer in the struct dptr_struct. Since the
code that calls SMB_VFS_READDIR etc originates in smbd/dir.c we might
be able to avoid making this public.

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