smbd panic at find_oplock_types().
Jeremy Allison
jra at samba.org
Tue Sep 9 21:22:20 MDT 2014
On Tue, Sep 09, 2014 at 02:23:29PM -0700, Hemanth Thummala wrote:
> + if (req != NULL) {
> + set_share_mode(lck, fsp, get_current_uid(conn),
> + req->mid,
> + fsp->oplock_type);
> + }
>
> This way, we will never add internal shared mode locks to data base.
>
> Want to check with you before I really test these changes. Please correct
> me I am wrong.
Yeah, there is an interaction between base file and stream
share modes we need to get right.
>From source4/torture/raw/streams.c:
/*
* Test FILE_SHARE_DELETE on streams
*
* A stream opened with !FILE_SHARE_DELETE prevents the main file to be opened
* with SEC_STD_DELETE.
*
* The main file opened with !FILE_SHARE_DELETE does *not* prevent a stream to
* be opened with SEC_STD_DELETE.
*
* A stream held open with FILE_SHARE_DELETE allows the file to be
* deleted. After the main file is deleted, access to the open file descriptor
* still works, but all name-based access to both the main file as well as the
* stream is denied with DELETE pending.
*
* This means, an open of the main file with SEC_STD_DELETE should walk all
* streams and also open them with SEC_STD_DELETE. If any of these opens gives
* SHARING_VIOLATION, the main open fails.
*
* Closing the main file after delete_on_close has been set does not really
* unlink it but leaves the corresponding share mode entry with
* delete_on_close being set around until all streams are closed.
*
* Opening a stream must also look at the main file's share mode entry, look
* at the delete_on_close bit and potentially return DELETE_PENDING.
*/
And remember, you can open a stream on a different connection
to the open on the base file - which would map to a separate
smbd - so the share mode entry is needed.
Jeremy.
More information about the samba-technical
mailing list