access_mask needed for rename
Kenny Dinh
kdinh at peaxy.net
Wed Nov 2 18:29:33 UTC 2016
Hi all,
In the *can_rename* function in *source3/smbd/reply.c*, we check for of an
existing open handle's access_mask to have either DELETE_ACCESS or
FILE_WRITE_ATTRIBUTES to decide if the rename operation is allowed. This
means that if the file was opened with only FILE_WRITE_ATTRIBUTES without
DELETE_ACCESS, the rename would be allowed to go through. This failed the
smbtorture *smb2.rename.simple_no_delete *test.
The strict rule (which is what MS does) is to allow rename request to go
through only if DELETE_ACCESS is specified.
Was there any reason to relax to rule, (and deviate from the behavior on MS
server), to allow the rename to go through even when the file handle was
opened with only the FILE_WRITE_ATTRIBUTES access_mask?
Below is the function, and the line in question is 2685.
2654 static NTSTATUS can_rename(connection_struct *conn, files_struct *fsp,
2655 uint16_t dirtype)
2656 {
2657 if (!CAN_WRITE(conn)) {
2658 return NT_STATUS_MEDIA_WRITE_PROTECTED;
2659 }
2660
2661 if ((dirtype & (FILE_ATTRIBUTE_HIDDEN |
FILE_ATTRIBUTE_SYSTEM)) !=
2662 (FILE_ATTRIBUTE_HIDDEN |
FILE_ATTRIBUTE_SYSTEM)) {
2663 /* Only bother to read the DOS attribute if we might
deny the
2664 rename on the grounds of attribute missmatch. */
2665 uint32_t fmode = dos_mode(conn, fsp->fsp_name);
2666 if ((fmode & ~dirtype) & (FILE_ATTRIBUTE_HIDDEN |
FILE_ATTRIBUTE_SYSTEM)) {
2667 return NT_STATUS_NO_SUCH_FILE;
2668 }
2669 }
2670
2671 if (S_ISDIR(fsp->fsp_name->st.st_ex_mode)) {
2672 if (fsp->posix_flags &
(FSP_POSIX_FLAGS_OPEN|FSP_POSIX_FLAGS_RENAME)) {
2673 return NT_STATUS_OK;
2674 }
2675
2676 /* If no pathnames are open below this
2677 directory, allow the rename. */
2678
2679 if (file_find_subpath(fsp)) {
2680 return NT_STATUS_ACCESS_DENIED;
2681 }
2682 return NT_STATUS_OK;
2683 }
2684
*2685 if (fsp->access_mask & (DELETE_ACCESS|FILE_WRITE_ATTRIBUTES))
{*
*2686 return NT_STATUS_OK;*
*2687 }*
2688
2689 return NT_STATUS_ACCESS_DENIED;
2690 }
More information about the samba-technical
mailing list