Re: Permission denied when chainbuilding packages with mock

[Jeremy Allison <jra@samba.org>]

On Sun, Nov 07, 2021 at 10:10:17PM +0100, Julian Sikorski wrote:
>Hi,
>
>I have originally posted this to samba list but we were not able to 
>solve the issue:
>https://lists.samba.org/archive/samba/2021-September/237428.html
>
>In brief, I am getting seemingly random permission denied errors when 
>chainbuilding packages with mock and pointing the result dir to a 
>samba share:
>
>$ mock --chain --localrepo=/mnt/openmediavault/kernel -r 
>fedora-35-x86_64 goffice/goffice-0.10.50-2.fc35.src.rpm 
>gnumeric/gnumeric-1.12.50-2.fc36.src.rpm
>^^ this fails every time with: Error calculating checksum /mnt/openmediavault/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/goffice-0.10.50-2.fc35.x86_64.rpm: 
>(39, fsync failed: Permission denied)
>
>$ mock --chain --localrepo=/mnt/openmediavault/kernel -r 
>fedora-35-x86_64 goffice/goffice-0.10.50-1.fc35.src.rpm 
>gnumeric/gnumeric-1.12.50-2.fc36.src.rpm
>^^ this works when starting with goffice and goffice-devel packages 
>removed from /mnt/openmediavault/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35. 
>If goffice or goffice-devel packages are present in the resultdir, an 
>error will appear:
>Error calculating checksum /mnt/openmediavault/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/goffice-devel-0.10.50-2.fc35.x86_64.rpm: 
>(39, fsync failed: Permission denied)
>
>So, summing up:
>- same host
>- same target dir
>- same build target
>- effectively the same package [1]
>- different outcome
>
>The target dir is mounted on the samba server as:
>/dev/sda1 on /srv/dev-disk-by-label-omv type ext4 (rw,noexec,relatime,discard,stripe=8191,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)
>
>
>And on the client as:
>//odroidxu4.local/julian on /mnt/openmediavault type cifs (rw,relatime,vers=3.1.1,cache=strict,username=julas,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.0.220,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,nobrl,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,_netdev)
>
>On the server one can see errors like:
>[2021/11/07 15:45:48.710865, 10, pid=4069, effective(1000, 100), 
>real(1000, 0), class=smb2] 
>../source3/smbd/smb2_flush.c:138(smbd_smb2_flush_send)
>  smbd_smb2_flush: kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/goffice-0.10.50-2.fc35.x86_64.rpm 
>- fnum 3429228891
>[2021/11/07 15:45:48.710935,  3, pid=4069, effective(1000, 100), 
>real(1000, 0), class=smb2] 
>../source3/smbd/smb2_server.c:3195(smbd_smb2_request_error_ex)
>  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] 
>status[NT_STATUS_ACCESS_DENIED] || at ../source3/smbd/smb2_flush.c:82
>[2021/11/07 15:45:48.711013, 10, pid=4069, effective(1000, 100), 
>real(1000, 0), class=smb2] 
>../source3/smbd/smb2_server.c:3086(smbd_smb2_request_done_ex)
>  smbd_smb2_request_done_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] 
>body[8] dyn[yes:1] at ../source3/smbd/smb2_server.c:3243
>
>but it is not really clear _why_ is the access being denied. Any ideas 
>where to look? Thanks!

What debug log level are you using on th server ? To debug
something like this use log level 10.

fsync failed: Permission denied

is strange. I need to see what access mask the fsp is being
opened with. If it's a directory, it might be running into
this (from smbd_smb2_flush_send()):

         if (!CHECK_WRITE(fsp)) {
                 bool allow_dir_flush = false;
                 uint32_t flush_access = FILE_ADD_FILE | FILE_ADD_SUBDIRECTORY;

                 if (!fsp->fsp_flags.is_directory) {
                         tevent_req_nterror(req, NT_STATUS_ACCESS_DENIED);
                         return tevent_req_post(req, ev);
                 }

                 /*
                  * Directories are not writable in the conventional
                  * sense, but if opened with *either*
                  * FILE_ADD_FILE or FILE_ADD_SUBDIRECTORY
                  * they can be flushed.
                  */

                 if ((fsp->access_mask & flush_access) != 0) {
                         allow_dir_flush = true;
                 }

                 if (allow_dir_flush == false) {
                         tevent_req_nterror(req, NT_STATUS_ACCESS_DENIED);
                         return tevent_req_post(req, ev);
                 }
         }

as 'man 2 fsync' on Linux doesn't show EACCES as a possible return
error from fsync.

If this is the case, then the client redirector is relying on Linux-specific
behavior. From 'man 2 fsync':

NOTES
        On some UNIX systems (but not Linux), fd must be a writable file descriptor.