Fixed nastly little bug where client was sending open_and_X call

with smb_mode (smb_vwv[3]) of 0x20 == DENY_WRITE + read-only-open.
and smb_ofun (smb_vwv[8]) of 0x11 == Create if not exist plus append
on a read-only share.
This was mapped into the strange unix flags of (O_RDONLY|O_CREAT)
- essentially O_CREAT as O_RDONLY == 0.
We were checking the unix flags directly against O_RDONLY instead
of masking off the open mode flag bits before doing the comparison,
so this open was being refused even though it was valid on a
read-only share.
Also ensured that the O_CREAT bit was masked out of the flags
bit if the open was done on a read-only share (as doing a unix
open( filename, O_RDONLY|O_CREAT, xxx) will create a zero length
file if the user had permission to write into the directory - which
should be denied on a read-only share.
Thanks to Mark Peek @ Whistle for giving me this test case.
Jeremy.
(This used to be commit eae921ac632c8297836b85e909903da0602eac0e)

0 files changed, 0 insertions, 0 deletions