Permission denied when chainbuilding packages with mock

Permission denied when chainbuilding packages with mock

[Julian Sikorski]

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!

Best regards,
Julian

Re: Permission denied when chainbuilding packages with mock

[Julian Sikorski]

Am 15.11.21 um 04:25 schrieb Steve French:
> The patch is in Linus's tree, so you should be able to try it with the
> weekly kernel updates for various distros which have download sites
> for more current kernel packages (Ubuntu, Fedora etc.) or build kernel
> yourself if you prefer.
> 
> To get it into stable we will need to send a followup email as
> described in their process guide below:
> 
> "send an email to stable@vger.kernel.org containing the subject of the
> patch, the commit ID, why you think it should be applied"
> 
> but some of the distros will apply it automatically (it is still
> helpful to send the email to stable as a reminder)
> 
Thank you. I found the patch in the Linus' tree yesterday and I saw you 
have just sent the email to stable. So it looks like we are all set. 
Thank you again for fixing this so quickly.

Best regards,
Julian

> On Sat, Nov 13, 2021 at 9:37 AM Julian Sikorski <belegdol@gmail.com> wrote:
>>
>> Am 10.11.21 um 12:23 schrieb Julian Sikorski:
>>> W dniu 10.11.2021 o 08:56, Steve French pisze:
>>>> Fix for the kernel client attached
>>>>
>>>>
>>>> On Tue, Nov 9, 2021 at 6:54 PM Jeremy Allison <jra@samba.org> wrote:
>>>>>
>>>>> On Tue, Nov 09, 2021 at 10:26:59AM +0100, Julian Sikorski wrote:
>>>>>> Am 09.11.21 um 09:10 schrieb Steve French:
>>>>>>> Yes - here is a trivial reproducer (excuse the ugly sample
>>>>>>> cut-n-paste)
>>>>>>>
>>>>>>> #include <stdio.h>
>>>>>>> #include <stdlib.h>
>>>>>>> #include <unistd.h>
>>>>>>> #include <string.h>
>>>>>>> #include <fcntl.h>
>>>>>>> #include <sys/types.h>
>>>>>>> #include <sys/stat.h>
>>>>>>>
>>>>>>> int main(int argc, char *argv[]) {
>>>>>>> char *str = "Text to be added";
>>>>>>> int fd, ret, fsyncrc, fsyncr_rc, openrc, closerc, close2rc;
>>>>>>>
>>>>>>> fd = creat("test.txt", S_IWUSR | S_IRUSR);
>>>>>>> if (fd < 0) {
>>>>>>> perror("creat()");
>>>>>>> exit(1);
>>>>>>> }
>>>>>>> ret = write(fd, str, strlen(str));
>>>>>>> if (ret < 0) {
>>>>>>> perror("write()");
>>>>>>> exit(1);
>>>>>>> }
>>>>>>> openrc = open("test.txt", O_RDONLY);
>>>>>>>           if (openrc < 0) {
>>>>>>>                   perror("creat()");
>>>>>>>                   exit(1);
>>>>>>>           }
>>>>>>> fsyncr_rc = fsync(openrc);
>>>>>>> if (fsyncr_rc < 0)
>>>>>>> perror("fsync()");
>>>>>>> fsyncrc = fsync(fd);
>>>>>>> closerc = close(fd);
>>>>>>> close2rc = close(openrc);
>>>>>>> printf("read fsync rc=%d, write fsync rc=%d, close rc=%d, RO close
>>>>>>> rc=%d\n", fsyncr_rc, fsyncrc, closerc, close2rc);
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>> I can confirm this fails on my machine without nostrictsync:
>>>>>>
>>>>>> $ ./test
>>>>>>
>>>>>> fsync(): Permission denied
>>>>>>
>>>>>> read fsync rc=-1, write fsync rc=0, close rc=0, RO close rc=0
>>>>>>
>>>>>> and works with nostrictsync:
>>>>>>
>>>>>> $ ./test
>>>>>>
>>>>>> read fsync rc=0, write fsync rc=0, close rc=0, RO close rc=0
>>>>>>
>>>>>> So is the bug in the Linux kernel?
>>>>>
>>>>> Yes, it's in the kernel cifsfs module which is forwarding an
>>>>> SMB_FLUSH request
>>>>> (which the spec says must fail on a non-writable handle) to
>>>>> a handle opened as non-writable. Steve hopefully will fix :-).
>>>>
>>>>
>>>>
>>> Thank you. I can confirm that 5.15.1 kernel with this patch applied [1]
>>> works both with the test case you provided earlier as well as with mock
>>> chainbuilds without the need for the nostrictsync mount option. Fedora
>>> kernel-5.14.16-301.fc35.x86_64 was failing without it.
>>>
>>> Tested-by: Julian Sikorski <belegdol@gmail.com>
>>>
>>> Best regards,
>>> Julian
>>>
>>> [1] https://gitlab.com/belegdol/kernel-ark/-/commits/fedora-5.15-cifs-fix/
>>
>> Hi,
>>
>> may I ask what the usual process of getting the patch into the Linus's
>> tree and to the stable branches is? If it takes longer, I am going to go
>> back to nostrictsync for now.
>>
>> Best regards,
>> Julian
> 
> 
> 

Re: Permission denied when chainbuilding packages with mock

[Steve French]

The patch is in Linus's tree, so you should be able to try it with the
weekly kernel updates for various distros which have download sites
for more current kernel packages (Ubuntu, Fedora etc.) or build kernel
yourself if you prefer.

To get it into stable we will need to send a followup email as
described in their process guide below:

"send an email to stable@vger.kernel.org containing the subject of the
patch, the commit ID, why you think it should be applied"

but some of the distros will apply it automatically (it is still
helpful to send the email to stable as a reminder)

On Sat, Nov 13, 2021 at 9:37 AM Julian Sikorski <belegdol@gmail.com> wrote:
>
> Am 10.11.21 um 12:23 schrieb Julian Sikorski:
> > W dniu 10.11.2021 o 08:56, Steve French pisze:
> >> Fix for the kernel client attached
> >>
> >>
> >> On Tue, Nov 9, 2021 at 6:54 PM Jeremy Allison <jra@samba.org> wrote:
> >>>
> >>> On Tue, Nov 09, 2021 at 10:26:59AM +0100, Julian Sikorski wrote:
> >>>> Am 09.11.21 um 09:10 schrieb Steve French:
> >>>>> Yes - here is a trivial reproducer (excuse the ugly sample
> >>>>> cut-n-paste)
> >>>>>
> >>>>> #include <stdio.h>
> >>>>> #include <stdlib.h>
> >>>>> #include <unistd.h>
> >>>>> #include <string.h>
> >>>>> #include <fcntl.h>
> >>>>> #include <sys/types.h>
> >>>>> #include <sys/stat.h>
> >>>>>
> >>>>> int main(int argc, char *argv[]) {
> >>>>> char *str = "Text to be added";
> >>>>> int fd, ret, fsyncrc, fsyncr_rc, openrc, closerc, close2rc;
> >>>>>
> >>>>> fd = creat("test.txt", S_IWUSR | S_IRUSR);
> >>>>> if (fd < 0) {
> >>>>> perror("creat()");
> >>>>> exit(1);
> >>>>> }
> >>>>> ret = write(fd, str, strlen(str));
> >>>>> if (ret < 0) {
> >>>>> perror("write()");
> >>>>> exit(1);
> >>>>> }
> >>>>> openrc = open("test.txt", O_RDONLY);
> >>>>>          if (openrc < 0) {
> >>>>>                  perror("creat()");
> >>>>>                  exit(1);
> >>>>>          }
> >>>>> fsyncr_rc = fsync(openrc);
> >>>>> if (fsyncr_rc < 0)
> >>>>> perror("fsync()");
> >>>>> fsyncrc = fsync(fd);
> >>>>> closerc = close(fd);
> >>>>> close2rc = close(openrc);
> >>>>> printf("read fsync rc=%d, write fsync rc=%d, close rc=%d, RO close
> >>>>> rc=%d\n", fsyncr_rc, fsyncrc, closerc, close2rc);
> >>>>> }
> >>>>>
> >>>>
> >>>> I can confirm this fails on my machine without nostrictsync:
> >>>>
> >>>> $ ./test
> >>>>
> >>>> fsync(): Permission denied
> >>>>
> >>>> read fsync rc=-1, write fsync rc=0, close rc=0, RO close rc=0
> >>>>
> >>>> and works with nostrictsync:
> >>>>
> >>>> $ ./test
> >>>>
> >>>> read fsync rc=0, write fsync rc=0, close rc=0, RO close rc=0
> >>>>
> >>>> So is the bug in the Linux kernel?
> >>>
> >>> Yes, it's in the kernel cifsfs module which is forwarding an
> >>> SMB_FLUSH request
> >>> (which the spec says must fail on a non-writable handle) to
> >>> a handle opened as non-writable. Steve hopefully will fix :-).
> >>
> >>
> >>
> > Thank you. I can confirm that 5.15.1 kernel with this patch applied [1]
> > works both with the test case you provided earlier as well as with mock
> > chainbuilds without the need for the nostrictsync mount option. Fedora
> > kernel-5.14.16-301.fc35.x86_64 was failing without it.
> >
> > Tested-by: Julian Sikorski <belegdol@gmail.com>
> >
> > Best regards,
> > Julian
> >
> > [1] https://gitlab.com/belegdol/kernel-ark/-/commits/fedora-5.15-cifs-fix/
>
> Hi,
>
> may I ask what the usual process of getting the patch into the Linus's
> tree and to the stable branches is? If it takes longer, I am going to go
> back to nostrictsync for now.
>
> Best regards,
> Julian



-- 
Thanks,

Steve

Re: Permission denied when chainbuilding packages with mock

[Julian Sikorski]

Am 10.11.21 um 12:23 schrieb Julian Sikorski:
> W dniu 10.11.2021 o 08:56, Steve French pisze:
>> Fix for the kernel client attached
>>
>>
>> On Tue, Nov 9, 2021 at 6:54 PM Jeremy Allison <jra@samba.org> wrote:
>>>
>>> On Tue, Nov 09, 2021 at 10:26:59AM +0100, Julian Sikorski wrote:
>>>> Am 09.11.21 um 09:10 schrieb Steve French:
>>>>> Yes - here is a trivial reproducer (excuse the ugly sample 
>>>>> cut-n-paste)
>>>>>
>>>>> #include <stdio.h>
>>>>> #include <stdlib.h>
>>>>> #include <unistd.h>
>>>>> #include <string.h>
>>>>> #include <fcntl.h>
>>>>> #include <sys/types.h>
>>>>> #include <sys/stat.h>
>>>>>
>>>>> int main(int argc, char *argv[]) {
>>>>> char *str = "Text to be added";
>>>>> int fd, ret, fsyncrc, fsyncr_rc, openrc, closerc, close2rc;
>>>>>
>>>>> fd = creat("test.txt", S_IWUSR | S_IRUSR);
>>>>> if (fd < 0) {
>>>>> perror("creat()");
>>>>> exit(1);
>>>>> }
>>>>> ret = write(fd, str, strlen(str));
>>>>> if (ret < 0) {
>>>>> perror("write()");
>>>>> exit(1);
>>>>> }
>>>>> openrc = open("test.txt", O_RDONLY);
>>>>>          if (openrc < 0) {
>>>>>                  perror("creat()");
>>>>>                  exit(1);
>>>>>          }
>>>>> fsyncr_rc = fsync(openrc);
>>>>> if (fsyncr_rc < 0)
>>>>> perror("fsync()");
>>>>> fsyncrc = fsync(fd);
>>>>> closerc = close(fd);
>>>>> close2rc = close(openrc);
>>>>> printf("read fsync rc=%d, write fsync rc=%d, close rc=%d, RO close
>>>>> rc=%d\n", fsyncr_rc, fsyncrc, closerc, close2rc);
>>>>> }
>>>>>
>>>>
>>>> I can confirm this fails on my machine without nostrictsync:
>>>>
>>>> $ ./test
>>>>
>>>> fsync(): Permission denied
>>>>
>>>> read fsync rc=-1, write fsync rc=0, close rc=0, RO close rc=0
>>>>
>>>> and works with nostrictsync:
>>>>
>>>> $ ./test
>>>>
>>>> read fsync rc=0, write fsync rc=0, close rc=0, RO close rc=0
>>>>
>>>> So is the bug in the Linux kernel?
>>>
>>> Yes, it's in the kernel cifsfs module which is forwarding an 
>>> SMB_FLUSH request
>>> (which the spec says must fail on a non-writable handle) to
>>> a handle opened as non-writable. Steve hopefully will fix :-).
>>
>>
>>
> Thank you. I can confirm that 5.15.1 kernel with this patch applied [1] 
> works both with the test case you provided earlier as well as with mock 
> chainbuilds without the need for the nostrictsync mount option. Fedora 
> kernel-5.14.16-301.fc35.x86_64 was failing without it.
> 
> Tested-by: Julian Sikorski <belegdol@gmail.com>
> 
> Best regards,
> Julian
> 
> [1] https://gitlab.com/belegdol/kernel-ark/-/commits/fedora-5.15-cifs-fix/

Hi,

may I ask what the usual process of getting the patch into the Linus's 
tree and to the stable branches is? If it takes longer, I am going to go 
back to nostrictsync for now.

Best regards,
Julian

Re: Permission denied when chainbuilding packages with mock

[Julian Sikorski]

W dniu 10.11.2021 o 08:56, Steve French pisze:
> Fix for the kernel client attached
> 
> 
> On Tue, Nov 9, 2021 at 6:54 PM Jeremy Allison <jra@samba.org> wrote:
>>
>> On Tue, Nov 09, 2021 at 10:26:59AM +0100, Julian Sikorski wrote:
>>> Am 09.11.21 um 09:10 schrieb Steve French:
>>>> Yes - here is a trivial reproducer (excuse the ugly sample cut-n-paste)
>>>>
>>>> #include <stdio.h>
>>>> #include <stdlib.h>
>>>> #include <unistd.h>
>>>> #include <string.h>
>>>> #include <fcntl.h>
>>>> #include <sys/types.h>
>>>> #include <sys/stat.h>
>>>>
>>>> int main(int argc, char *argv[]) {
>>>> char *str = "Text to be added";
>>>> int fd, ret, fsyncrc, fsyncr_rc, openrc, closerc, close2rc;
>>>>
>>>> fd = creat("test.txt", S_IWUSR | S_IRUSR);
>>>> if (fd < 0) {
>>>> perror("creat()");
>>>> exit(1);
>>>> }
>>>> ret = write(fd, str, strlen(str));
>>>> if (ret < 0) {
>>>> perror("write()");
>>>> exit(1);
>>>> }
>>>> openrc = open("test.txt", O_RDONLY);
>>>>          if (openrc < 0) {
>>>>                  perror("creat()");
>>>>                  exit(1);
>>>>          }
>>>> fsyncr_rc = fsync(openrc);
>>>> if (fsyncr_rc < 0)
>>>> perror("fsync()");
>>>> fsyncrc = fsync(fd);
>>>> closerc = close(fd);
>>>> close2rc = close(openrc);
>>>> printf("read fsync rc=%d, write fsync rc=%d, close rc=%d, RO close
>>>> rc=%d\n", fsyncr_rc, fsyncrc, closerc, close2rc);
>>>> }
>>>>
>>>
>>> I can confirm this fails on my machine without nostrictsync:
>>>
>>> $ ./test
>>>
>>> fsync(): Permission denied
>>>
>>> read fsync rc=-1, write fsync rc=0, close rc=0, RO close rc=0
>>>
>>> and works with nostrictsync:
>>>
>>> $ ./test
>>>
>>> read fsync rc=0, write fsync rc=0, close rc=0, RO close rc=0
>>>
>>> So is the bug in the Linux kernel?
>>
>> Yes, it's in the kernel cifsfs module which is forwarding an SMB_FLUSH request
>> (which the spec says must fail on a non-writable handle) to
>> a handle opened as non-writable. Steve hopefully will fix :-).
> 
> 
> 
Thank you. I can confirm that 5.15.1 kernel with this patch applied [1] 
works both with the test case you provided earlier as well as with mock 
chainbuilds without the need for the nostrictsync mount option. Fedora 
kernel-5.14.16-301.fc35.x86_64 was failing without it.

Tested-by: Julian Sikorski <belegdol@gmail.com>

Best regards,
Julian

[1] https://gitlab.com/belegdol/kernel-ark/-/commits/fedora-5.15-cifs-fix/

Re: Permission denied when chainbuilding packages with mock

[Steve French]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

Fix for the kernel client attached


On Tue, Nov 9, 2021 at 6:54 PM Jeremy Allison <jra@samba.org> wrote:
>
> On Tue, Nov 09, 2021 at 10:26:59AM +0100, Julian Sikorski wrote:
> >Am 09.11.21 um 09:10 schrieb Steve French:
> >>Yes - here is a trivial reproducer (excuse the ugly sample cut-n-paste)
> >>
> >>#include <stdio.h>
> >>#include <stdlib.h>
> >>#include <unistd.h>
> >>#include <string.h>
> >>#include <fcntl.h>
> >>#include <sys/types.h>
> >>#include <sys/stat.h>
> >>
> >>int main(int argc, char *argv[]) {
> >>char *str = "Text to be added";
> >>int fd, ret, fsyncrc, fsyncr_rc, openrc, closerc, close2rc;
> >>
> >>fd = creat("test.txt", S_IWUSR | S_IRUSR);
> >>if (fd < 0) {
> >>perror("creat()");
> >>exit(1);
> >>}
> >>ret = write(fd, str, strlen(str));
> >>if (ret < 0) {
> >>perror("write()");
> >>exit(1);
> >>}
> >>openrc = open("test.txt", O_RDONLY);
> >>         if (openrc < 0) {
> >>                 perror("creat()");
> >>                 exit(1);
> >>         }
> >>fsyncr_rc = fsync(openrc);
> >>if (fsyncr_rc < 0)
> >>perror("fsync()");
> >>fsyncrc = fsync(fd);
> >>closerc = close(fd);
> >>close2rc = close(openrc);
> >>printf("read fsync rc=%d, write fsync rc=%d, close rc=%d, RO close
> >>rc=%d\n", fsyncr_rc, fsyncrc, closerc, close2rc);
> >>}
> >>
> >
> >I can confirm this fails on my machine without nostrictsync:
> >
> >$ ./test
> >
> >fsync(): Permission denied
> >
> >read fsync rc=-1, write fsync rc=0, close rc=0, RO close rc=0
> >
> >and works with nostrictsync:
> >
> >$ ./test
> >
> >read fsync rc=0, write fsync rc=0, close rc=0, RO close rc=0
> >
> >So is the bug in the Linux kernel?
>
> Yes, it's in the kernel cifsfs module which is forwarding an SMB_FLUSH request
> (which the spec says must fail on a non-writable handle) to
> a handle opened as non-writable. Steve hopefully will fix :-).



-- 
Thanks,

Steve

[-- Attachment #2: 0001-smb3-do-not-error-on-fsync-when-readonly.patch --]
[-- Type: text/x-patch, Size: 2911 bytes --]

From da939857cdb6e25d0c967547f112eea07d847870 Mon Sep 17 00:00:00 2001
From: Steve French <stfrench@microsoft.com>
Date: Wed, 10 Nov 2021 01:47:48 -0600
Subject: [PATCH] smb3: do not error on fsync when readonly

Linux allows doing a flush/fsync on a file open for read-only,
but the protocol does not allow that.  If the file passed in
on the flush is read-only try to find a writeable handle for
the same inode, if that is not possible skip sending the
fsync call to the server to avoid breaking the apps.

Reported-by: Julian Sikorski <belegdol@gmail.com>
Suggested-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
---
 fs/cifs/file.c | 35 +++++++++++++++++++++++++++++------
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 1b855fcb179e..fed30ba56d5f 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -2692,12 +2692,23 @@ int cifs_strict_fsync(struct file *file, loff_t start, loff_t end,
 	tcon = tlink_tcon(smbfile->tlink);
 	if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NOSSYNC)) {
 		server = tcon->ses->server;
-		if (server->ops->flush)
-			rc = server->ops->flush(xid, tcon, &smbfile->fid);
-		else
+		if (server->ops->flush == NULL) {
 			rc = -ENOSYS;
+			goto strict_fsync_exit;
+		}
+
+		if ((OPEN_FMODE(smbfile->f_flags) & FMODE_WRITE) == 0) {
+			smbfile = find_writable_file(CIFS_I(inode), FIND_WR_ANY);
+			if (smbfile) {
+				rc = server->ops->flush(xid, tcon, &smbfile->fid);
+				cifsFileInfo_put(smbfile);
+			} else
+				cifs_dbg(FYI, "ignore fsync for file not open for write\n");
+		} else
+			rc = server->ops->flush(xid, tcon, &smbfile->fid);
 	}
 
+strict_fsync_exit:
 	free_xid(xid);
 	return rc;
 }
@@ -2709,6 +2720,7 @@ int cifs_fsync(struct file *file, loff_t start, loff_t end, int datasync)
 	struct cifs_tcon *tcon;
 	struct TCP_Server_Info *server;
 	struct cifsFileInfo *smbfile = file->private_data;
+	struct inode *inode = file_inode(file);
 	struct cifs_sb_info *cifs_sb = CIFS_FILE_SB(file);
 
 	rc = file_write_and_wait_range(file, start, end);
@@ -2725,12 +2737,23 @@ int cifs_fsync(struct file *file, loff_t start, loff_t end, int datasync)
 	tcon = tlink_tcon(smbfile->tlink);
 	if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NOSSYNC)) {
 		server = tcon->ses->server;
-		if (server->ops->flush)
-			rc = server->ops->flush(xid, tcon, &smbfile->fid);
-		else
+		if (server->ops->flush == NULL) {
 			rc = -ENOSYS;
+			goto fsync_exit;
+		}
+
+		if ((OPEN_FMODE(smbfile->f_flags) & FMODE_WRITE) == 0) {
+			smbfile = find_writable_file(CIFS_I(inode), FIND_WR_ANY);
+			if (smbfile) {
+				rc = server->ops->flush(xid, tcon, &smbfile->fid);
+				cifsFileInfo_put(smbfile);
+			} else
+				cifs_dbg(FYI, "ignore fsync for file not open for write\n");
+		} else
+			rc = server->ops->flush(xid, tcon, &smbfile->fid);
 	}
 
+fsync_exit:
 	free_xid(xid);
 	return rc;
 }
-- 
2.32.0

Re: Permission denied when chainbuilding packages with mock

[Jeremy Allison]

On Tue, Nov 09, 2021 at 10:26:59AM +0100, Julian Sikorski wrote:
>Am 09.11.21 um 09:10 schrieb Steve French:
>>Yes - here is a trivial reproducer (excuse the ugly sample cut-n-paste)
>>
>>#include <stdio.h>
>>#include <stdlib.h>
>>#include <unistd.h>
>>#include <string.h>
>>#include <fcntl.h>
>>#include <sys/types.h>
>>#include <sys/stat.h>
>>
>>int main(int argc, char *argv[]) {
>>char *str = "Text to be added";
>>int fd, ret, fsyncrc, fsyncr_rc, openrc, closerc, close2rc;
>>
>>fd = creat("test.txt", S_IWUSR | S_IRUSR);
>>if (fd < 0) {
>>perror("creat()");
>>exit(1);
>>}
>>ret = write(fd, str, strlen(str));
>>if (ret < 0) {
>>perror("write()");
>>exit(1);
>>}
>>openrc = open("test.txt", O_RDONLY);
>>         if (openrc < 0) {
>>                 perror("creat()");
>>                 exit(1);
>>         }
>>fsyncr_rc = fsync(openrc);
>>if (fsyncr_rc < 0)
>>perror("fsync()");
>>fsyncrc = fsync(fd);
>>closerc = close(fd);
>>close2rc = close(openrc);
>>printf("read fsync rc=%d, write fsync rc=%d, close rc=%d, RO close
>>rc=%d\n", fsyncr_rc, fsyncrc, closerc, close2rc);
>>}
>>
>
>I can confirm this fails on my machine without nostrictsync:
>
>$ ./test
>
>fsync(): Permission denied
>
>read fsync rc=-1, write fsync rc=0, close rc=0, RO close rc=0
>
>and works with nostrictsync:
>
>$ ./test
>
>read fsync rc=0, write fsync rc=0, close rc=0, RO close rc=0
>
>So is the bug in the Linux kernel?

Yes, it's in the kernel cifsfs module which is forwarding an SMB_FLUSH request
(which the spec says must fail on a non-writable handle) to
a handle opened as non-writable. Steve hopefully will fix :-).

Re: Permission denied when chainbuilding packages with mock

[Jeremy Allison]

On Tue, Nov 09, 2021 at 02:10:19AM -0600, Steve French wrote:
>Yes - here is a trivial reproducer (excuse the ugly sample cut-n-paste)
>
>#include <stdio.h>
>#include <stdlib.h>
>#include <unistd.h>
>#include <string.h>
>#include <fcntl.h>
>#include <sys/types.h>
>#include <sys/stat.h>
>
>int main(int argc, char *argv[]) {
>char *str = "Text to be added";
>int fd, ret, fsyncrc, fsyncr_rc, openrc, closerc, close2rc;
>
>fd = creat("test.txt", S_IWUSR | S_IRUSR);
>if (fd < 0) {
>perror("creat()");
>exit(1);
>}
>ret = write(fd, str, strlen(str));
>if (ret < 0) {
>perror("write()");
>exit(1);
>}
>openrc = open("test.txt", O_RDONLY);
>        if (openrc < 0) {
>                perror("creat()");
>                exit(1);
>        }
>fsyncr_rc = fsync(openrc);
>if (fsyncr_rc < 0)
>perror("fsync()");
>fsyncrc = fsync(fd);
>closerc = close(fd);
>close2rc = close(openrc);
>printf("read fsync rc=%d, write fsync rc=%d, close rc=%d, RO close
>rc=%d\n", fsyncr_rc, fsyncrc, closerc, close2rc);
>}

Yep, I expected such. cifsfs needs to keep track of
open mode and silently eat fsync calls on non-writeable
files/directory opens.

Re: Permission denied when chainbuilding packages with mock

[Julian Sikorski]

Am 09.11.21 um 09:10 schrieb Steve French:
> Yes - here is a trivial reproducer (excuse the ugly sample cut-n-paste)
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <string.h>
> #include <fcntl.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> 
> int main(int argc, char *argv[]) {
> char *str = "Text to be added";
> int fd, ret, fsyncrc, fsyncr_rc, openrc, closerc, close2rc;
> 
> fd = creat("test.txt", S_IWUSR | S_IRUSR);
> if (fd < 0) {
> perror("creat()");
> exit(1);
> }
> ret = write(fd, str, strlen(str));
> if (ret < 0) {
> perror("write()");
> exit(1);
> }
> openrc = open("test.txt", O_RDONLY);
>          if (openrc < 0) {
>                  perror("creat()");
>                  exit(1);
>          }
> fsyncr_rc = fsync(openrc);
> if (fsyncr_rc < 0)
> perror("fsync()");
> fsyncrc = fsync(fd);
> closerc = close(fd);
> close2rc = close(openrc);
> printf("read fsync rc=%d, write fsync rc=%d, close rc=%d, RO close
> rc=%d\n", fsyncr_rc, fsyncrc, closerc, close2rc);
> }
> 

I can confirm this fails on my machine without nostrictsync:

$ ./test

fsync(): Permission denied

read fsync rc=-1, write fsync rc=0, close rc=0, RO close rc=0

and works with nostrictsync:

$ ./test

read fsync rc=0, write fsync rc=0, close rc=0, RO close rc=0

So is the bug in the Linux kernel?

Best regards,
Julian

Re: Permission denied when chainbuilding packages with mock

[Steve French]

Yes - here is a trivial reproducer (excuse the ugly sample cut-n-paste)

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>

int main(int argc, char *argv[]) {
char *str = "Text to be added";
int fd, ret, fsyncrc, fsyncr_rc, openrc, closerc, close2rc;

fd = creat("test.txt", S_IWUSR | S_IRUSR);
if (fd < 0) {
perror("creat()");
exit(1);
}
ret = write(fd, str, strlen(str));
if (ret < 0) {
perror("write()");
exit(1);
}
openrc = open("test.txt", O_RDONLY);
        if (openrc < 0) {
                perror("creat()");
                exit(1);
        }
fsyncr_rc = fsync(openrc);
if (fsyncr_rc < 0)
perror("fsync()");
fsyncrc = fsync(fd);
closerc = close(fd);
close2rc = close(openrc);
printf("read fsync rc=%d, write fsync rc=%d, close rc=%d, RO close
rc=%d\n", fsyncr_rc, fsyncrc, closerc, close2rc);
}

On Mon, Nov 8, 2021 at 10:47 AM Jeremy Allison <jra@samba.org> wrote:
>
> On Mon, Nov 08, 2021 at 07:59:49AM +0100, Julian Sikorski wrote:
> >I will try to generate a log for the working case later. Having said
> >that, the question becomes: why are some files read-only but others
> >are not, when they are generated by the same software in the same
> >folder? The permissions on both folders are exactly the same:
>
> It's nothing to do with the permissions on the files. It's to
> do with the open mode the client uses when opening the file.



-- 
Thanks,

Steve

Re: Permission denied when chainbuilding packages with mock

[Jeremy Allison]

On Mon, Nov 08, 2021 at 07:59:49AM +0100, Julian Sikorski wrote:
>I will try to generate a log for the working case later. Having said 
>that, the question becomes: why are some files read-only but others 
>are not, when they are generated by the same software in the same 
>folder? The permissions on both folders are exactly the same:

It's nothing to do with the permissions on the files. It's to
do with the open mode the client uses when opening the file.

Re: Permission denied when chainbuilding packages with mock

[Julian Sikorski]

W dniu 08.11.2021 o 07:59, Julian Sikorski pisze:
> 
> 
> Am 08.11.21 um 02:48 schrieb Jeremy Allison:
>> On Sun, Nov 07, 2021 at 11:51:37PM +0100, Julian Sikorski wrote:
>>
>>> Thanks, this looks promising. Do you have any guesses as to why it 
>>> works for goffice-0.10.50-1.fc35 but not with goffice-0.10.50-2.fc35? 
>>> Race condition?
>>
>> No clue, sorry. I'd need to see comparative traces - but all that
>> will tell me is that it isn't doing the fsync on a read-only file.
> 
> I will try to generate a log for the working case later. Having said 
> that, the question becomes: why are some files read-only but others are 
> not, when they are generated by the same software in the same folder? 
> The permissions on both folders are exactly the same:
> 
> $ ls -l 
> /mnt/openmediavault/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/
> 
> insgesamt 15360
> 
> -rwxr-xr-x. 1 julas julas  864488  7. Nov 23:53 build.log
> 
> -rwxr-xr-x. 1 julas julas 2443249  7. Nov 16:39 
> goffice-0.10.50-2.fc35.src.rpm
> 
> -rwxr-xr-x. 1 julas julas 2051776  7. Nov 16:39 
> goffice-0.10.50-2.fc35.x86_64.rpm
> 
> -rwxr-xr-x. 1 julas julas 2195483  7. Nov 16:39 
> goffice-debuginfo-0.10.50-2.fc35.x86_64.rpm
> 
> -rwxr-xr-x. 1 julas julas  967394  7. Nov 16:39 
> goffice-debugsource-0.10.50-2.fc35.x86_64.rpm
> 
> -rwxr-xr-x. 1 julas julas  339221  7. Nov 16:39 
> goffice-devel-0.10.50-2.fc35.x86_64.rpm
> 
> -rwxr-xr-x. 1 julas julas    3050  7. Nov 16:38 hw_info.log
> 
> -rwxr-xr-x. 1 julas julas   37268  7. Nov 16:38 installed_pkgs.log
> 
> drwxr-xr-x. 2 julas julas       0  7. Nov 16:39 repodata
> 
> -rwxr-xr-x. 1 julas julas  301702  7. Nov 23:53 root.log
> 
> -rwxr-xr-x. 1 julas julas    1710  7. Nov 23:53 state.log
> 
> -rwxr-xr-x. 1 julas julas       0  7. Nov 16:39 success
> 
> $ ls -l 
> /mnt/openmediavault/kernel/results/fedora-35-x86_64/goffice-0.10.50-1.fc35/
> 
> insgesamt 15360
> 
> -rwxr-xr-x. 1 julas julas  864469  7. Nov 16:34 build.log
> 
> -rwxr-xr-x. 1 julas julas 2443099  7. Nov 16:30 
> goffice-0.10.50-1.fc35.src.rpm
> 
> -rwxr-xr-x. 1 julas julas 2051631  7. Nov 16:30 
> goffice-0.10.50-1.fc35.x86_64.rpm
> 
> -rwxr-xr-x. 1 julas julas 2192839  7. Nov 16:30 
> goffice-debuginfo-0.10.50-1.fc35.x86_64.rpm
> 
> -rwxr-xr-x. 1 julas julas  967236  7. Nov 16:30 
> goffice-debugsource-0.10.50-1.fc35.x86_64.rpm
> 
> -rwxr-xr-x. 1 julas julas  339086  7. Nov 16:30 
> goffice-devel-0.10.50-1.fc35.x86_64.rpm
> 
> -rwxr-xr-x. 1 julas julas    3050  7. Nov 16:29 hw_info.log
> 
> -rwxr-xr-x. 1 julas julas   37268  7. Nov 16:29 installed_pkgs.log
> 
> drwxr-xr-x. 2 julas julas       0  7. Nov 16:30 repodata
> 
> -rwxr-xr-x. 1 julas julas  301199  7. Nov 16:34 root.log
> 
> -rwxr-xr-x. 1 julas julas    1665  7. Nov 16:34 state.log
> 
> -rwxr-xr-x. 1 julas julas       0  7. Nov 16:30 success
> 
> 
> The other explanation could be that the software (mock) runs fsync on 
> some of the files but not on others.
> 
> Best regards,
> Julian
I have now generated the logs from the working case:

https://www.dropbox.com/sh/9ucxoeia727xu3k/AABYiTQ0aBqCqnNL9Vz3Jch8a?dl=0

the moment at which failure would have happened is around 16:46:11.

Best regards,
Julian

Re: Permission denied when chainbuilding packages with mock

[Julian Sikorski]

Am 08.11.21 um 02:48 schrieb Jeremy Allison:
> On Sun, Nov 07, 2021 at 11:51:37PM +0100, Julian Sikorski wrote:
> 
>> Thanks, this looks promising. Do you have any guesses as to why it 
>> works for goffice-0.10.50-1.fc35 but not with goffice-0.10.50-2.fc35? 
>> Race condition?
> 
> No clue, sorry. I'd need to see comparative traces - but all that
> will tell me is that it isn't doing the fsync on a read-only file.

I will try to generate a log for the working case later. Having said 
that, the question becomes: why are some files read-only but others are 
not, when they are generated by the same software in the same folder? 
The permissions on both folders are exactly the same:

$ ls -l 
/mnt/openmediavault/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/

insgesamt 15360

-rwxr-xr-x. 1 julas julas  864488  7. Nov 23:53 build.log

-rwxr-xr-x. 1 julas julas 2443249  7. Nov 16:39 
goffice-0.10.50-2.fc35.src.rpm

-rwxr-xr-x. 1 julas julas 2051776  7. Nov 16:39 
goffice-0.10.50-2.fc35.x86_64.rpm

-rwxr-xr-x. 1 julas julas 2195483  7. Nov 16:39 
goffice-debuginfo-0.10.50-2.fc35.x86_64.rpm

-rwxr-xr-x. 1 julas julas  967394  7. Nov 16:39 
goffice-debugsource-0.10.50-2.fc35.x86_64.rpm

-rwxr-xr-x. 1 julas julas  339221  7. Nov 16:39 
goffice-devel-0.10.50-2.fc35.x86_64.rpm

-rwxr-xr-x. 1 julas julas    3050  7. Nov 16:38 hw_info.log

-rwxr-xr-x. 1 julas julas   37268  7. Nov 16:38 installed_pkgs.log

drwxr-xr-x. 2 julas julas       0  7. Nov 16:39 repodata

-rwxr-xr-x. 1 julas julas  301702  7. Nov 23:53 root.log

-rwxr-xr-x. 1 julas julas    1710  7. Nov 23:53 state.log

-rwxr-xr-x. 1 julas julas       0  7. Nov 16:39 success

$ ls -l 
/mnt/openmediavault/kernel/results/fedora-35-x86_64/goffice-0.10.50-1.fc35/

insgesamt 15360

-rwxr-xr-x. 1 julas julas  864469  7. Nov 16:34 build.log

-rwxr-xr-x. 1 julas julas 2443099  7. Nov 16:30 
goffice-0.10.50-1.fc35.src.rpm

-rwxr-xr-x. 1 julas julas 2051631  7. Nov 16:30 
goffice-0.10.50-1.fc35.x86_64.rpm

-rwxr-xr-x. 1 julas julas 2192839  7. Nov 16:30 
goffice-debuginfo-0.10.50-1.fc35.x86_64.rpm

-rwxr-xr-x. 1 julas julas  967236  7. Nov 16:30 
goffice-debugsource-0.10.50-1.fc35.x86_64.rpm

-rwxr-xr-x. 1 julas julas  339086  7. Nov 16:30 
goffice-devel-0.10.50-1.fc35.x86_64.rpm

-rwxr-xr-x. 1 julas julas    3050  7. Nov 16:29 hw_info.log

-rwxr-xr-x. 1 julas julas   37268  7. Nov 16:29 installed_pkgs.log

drwxr-xr-x. 2 julas julas       0  7. Nov 16:30 repodata

-rwxr-xr-x. 1 julas julas  301199  7. Nov 16:34 root.log

-rwxr-xr-x. 1 julas julas    1665  7. Nov 16:34 state.log

-rwxr-xr-x. 1 julas julas       0  7. Nov 16:30 success


The other explanation could be that the software (mock) runs fsync on 
some of the files but not on others.

Best regards,
Julian

Re: Permission denied when chainbuilding packages with mock

[Jeremy Allison]

On Sun, Nov 07, 2021 at 11:51:37PM +0100, Julian Sikorski wrote:

>Thanks, this looks promising. Do you have any guesses as to why it 
>works for goffice-0.10.50-1.fc35 but not with goffice-0.10.50-2.fc35? 
>Race condition?

No clue, sorry. I'd need to see comparative traces - but all that
will tell me is that it isn't doing the fsync on a read-only file.

Re: Permission denied when chainbuilding packages with mock

[Jeremy Allison]

On Sun, Nov 07, 2021 at 04:50:21PM -0600, Steve French wrote:
>That is interesting ... and weird.   Why would POSIX allow doing
>something write related (fsync) without write permission?

It's not POSIX, it's Linux :-).

It also operates on meta-data, so if the buffer cache
has any pending changes on a read-only fd, then fsync(fd)
will flush them.

man 2 fsync.

..
        As well as flushing the file data, fsync() also  flushes  the  metadata
        information associated with the file (see inode(7)).

I think cifsfs needs to keep track of the file modes
and silently return success on a read-only fd even
if mounted without nostrictsync.

Re: Permission denied when chainbuilding packages with mock

[Julian Sikorski]

W dniu 07.11.2021 o 23:50, Steve French pisze:
> That is interesting ... and weird.   Why would POSIX allow doing
> something write related (fsync) without write permission?
> 
> To work around this (especially if the server is reliable enough) -
> simply mount with "nostrictsync" (we will write out cached writes to
> the server on flush, but won't send the fsync).
> 
> Will look at it more.

Mounting with nostrictsync has made the problem go away. Thank you both!

Best regards,
Julian

> 
> On Sun, Nov 7, 2021 at 4:47 PM Jeremy Allison <jra@samba.org> wrote:
>>
>> On Sun, Nov 07, 2021 at 11:15:49PM +0100, Julian Sikorski wrote:
>>> Hi,
>>>
>>> thanks for responding. I am using loglevel 10. I have uploaded the
>>> logs to my dropbox as they are too big to attach:
>>>
>>> https://www.dropbox.com/sh/r4b7q7ti2zmtlu9/AACqFY0FW2oW41Vu8l3nLZJSa?dl=0
>>>
>>> The problem happens around 15:45:48. Do the logs show what access mask
>>> the fsp is being opened with you requested?
>>> I am using quite an old samba server (4.9.5+dfsg-5+deb10u1) due to the
>>> fact that openmediavault is based off debian 10 and there are no samba
>>> backports available. Having said that, this configuration can work, as
>>> shown by goffice/goffice-0.10.50-1.fc35.src.rpm rebuild and the fact
>>> that it was working before for months previously.
>>
>> The error is occurring on the file:
>>
>> /srv/dev-disk-by-label-omv/julian/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/goffice-devel-0.10.50-2.fc35.x86_64.rpm
>>
>> this is a regular file, not a directory
>> opened with ACCESS_MASK: 0x00120089
>>
>> that is:
>>
>> SEC_STD_SYNCHRONIZE|
>> SEC_STD_READ_CONTROL|
>> SEC_FILE_READ_ATTRIBUTE|
>> SEC_FILE_READ_EA|
>> SEC_FILE_READ_DATA
>>
>> so indeed, this is being opened *without*
>> SEC_FILE_WRITE_DATA|SEC_FILE_APPEND_DATA
>> so smbd is correct in returning ACCESS_DENIED
>> to an SMB2_FLUSH call.
>>
>> Looks like this is a client bug, in that it
>> is passing a Linux fsync(fd) call directly
>> to the SMB2 server without checking if the
>> underlying file is open for write access.
>>
>> In this case, the SMB2 client should just
>> return success to the caller, as any SMB_FLUSH
>> call will always return ACCESS_DENIED on a
>> non-writable file handle, and according to
>> Linux semantics calling fsync(fd) on an fd
>> open with O_RDNLY should return success.
>>
>> Steve, over to you :-).
>>
>> Jeremy.
> 
> 
> 

Re: Permission denied when chainbuilding packages with mock

[Julian Sikorski]

W dniu 07.11.2021 o 23:47, Jeremy Allison pisze:
> On Sun, Nov 07, 2021 at 11:15:49PM +0100, Julian Sikorski wrote:
>> Hi,
>>
>> thanks for responding. I am using loglevel 10. I have uploaded the 
>> logs to my dropbox as they are too big to attach:
>>
>> https://www.dropbox.com/sh/r4b7q7ti2zmtlu9/AACqFY0FW2oW41Vu8l3nLZJSa?dl=0
>>
>> The problem happens around 15:45:48. Do the logs show what access mask 
>> the fsp is being opened with you requested?
>> I am using quite an old samba server (4.9.5+dfsg-5+deb10u1) due to the 
>> fact that openmediavault is based off debian 10 and there are no samba 
>> backports available. Having said that, this configuration can work, as 
>> shown by goffice/goffice-0.10.50-1.fc35.src.rpm rebuild and the fact 
>> that it was working before for months previously.
> 
> The error is occurring on the file:
> 
> /srv/dev-disk-by-label-omv/julian/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/goffice-devel-0.10.50-2.fc35.x86_64.rpm 
> 
> 
> this is a regular file, not a directory
> opened with ACCESS_MASK: 0x00120089
> 
> that is:
> 
> SEC_STD_SYNCHRONIZE|
> SEC_STD_READ_CONTROL|
> SEC_FILE_READ_ATTRIBUTE|
> SEC_FILE_READ_EA|
> SEC_FILE_READ_DATA
> 
> so indeed, this is being opened *without*
> SEC_FILE_WRITE_DATA|SEC_FILE_APPEND_DATA
> so smbd is correct in returning ACCESS_DENIED
> to an SMB2_FLUSH call.
> 
> Looks like this is a client bug, in that it
> is passing a Linux fsync(fd) call directly
> to the SMB2 server without checking if the
> underlying file is open for write access.
> 
> In this case, the SMB2 client should just
> return success to the caller, as any SMB_FLUSH
> call will always return ACCESS_DENIED on a
> non-writable file handle, and according to
> Linux semantics calling fsync(fd) on an fd
> open with O_RDNLY should return success.
> 
> Steve, over to you :-).
> 
> Jeremy.
Thanks, this looks promising. Do you have any guesses as to why it works 
for goffice-0.10.50-1.fc35 but not with goffice-0.10.50-2.fc35? Race 
condition?

Best regards,
Julian

Re: Permission denied when chainbuilding packages with mock

[Steve French]

That is interesting ... and weird.   Why would POSIX allow doing
something write related (fsync) without write permission?

To work around this (especially if the server is reliable enough) -
simply mount with "nostrictsync" (we will write out cached writes to
the server on flush, but won't send the fsync).

Will look at it more.

On Sun, Nov 7, 2021 at 4:47 PM Jeremy Allison <jra@samba.org> wrote:
>
> On Sun, Nov 07, 2021 at 11:15:49PM +0100, Julian Sikorski wrote:
> >Hi,
> >
> >thanks for responding. I am using loglevel 10. I have uploaded the
> >logs to my dropbox as they are too big to attach:
> >
> >https://www.dropbox.com/sh/r4b7q7ti2zmtlu9/AACqFY0FW2oW41Vu8l3nLZJSa?dl=0
> >
> >The problem happens around 15:45:48. Do the logs show what access mask
> >the fsp is being opened with you requested?
> >I am using quite an old samba server (4.9.5+dfsg-5+deb10u1) due to the
> >fact that openmediavault is based off debian 10 and there are no samba
> >backports available. Having said that, this configuration can work, as
> >shown by goffice/goffice-0.10.50-1.fc35.src.rpm rebuild and the fact
> >that it was working before for months previously.
>
> The error is occurring on the file:
>
> /srv/dev-disk-by-label-omv/julian/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/goffice-devel-0.10.50-2.fc35.x86_64.rpm
>
> this is a regular file, not a directory
> opened with ACCESS_MASK: 0x00120089
>
> that is:
>
> SEC_STD_SYNCHRONIZE|
> SEC_STD_READ_CONTROL|
> SEC_FILE_READ_ATTRIBUTE|
> SEC_FILE_READ_EA|
> SEC_FILE_READ_DATA
>
> so indeed, this is being opened *without*
> SEC_FILE_WRITE_DATA|SEC_FILE_APPEND_DATA
> so smbd is correct in returning ACCESS_DENIED
> to an SMB2_FLUSH call.
>
> Looks like this is a client bug, in that it
> is passing a Linux fsync(fd) call directly
> to the SMB2 server without checking if the
> underlying file is open for write access.
>
> In this case, the SMB2 client should just
> return success to the caller, as any SMB_FLUSH
> call will always return ACCESS_DENIED on a
> non-writable file handle, and according to
> Linux semantics calling fsync(fd) on an fd
> open with O_RDNLY should return success.
>
> Steve, over to you :-).
>
> Jeremy.



-- 
Thanks,

Steve

Re: Permission denied when chainbuilding packages with mock

[Jeremy Allison]

On Sun, Nov 07, 2021 at 11:15:49PM +0100, Julian Sikorski wrote:
>Hi,
>
>thanks for responding. I am using loglevel 10. I have uploaded the 
>logs to my dropbox as they are too big to attach:
>
>https://www.dropbox.com/sh/r4b7q7ti2zmtlu9/AACqFY0FW2oW41Vu8l3nLZJSa?dl=0
>
>The problem happens around 15:45:48. Do the logs show what access mask 
>the fsp is being opened with you requested?
>I am using quite an old samba server (4.9.5+dfsg-5+deb10u1) due to the 
>fact that openmediavault is based off debian 10 and there are no samba 
>backports available. Having said that, this configuration can work, as 
>shown by goffice/goffice-0.10.50-1.fc35.src.rpm rebuild and the fact 
>that it was working before for months previously.

The error is occurring on the file:

/srv/dev-disk-by-label-omv/julian/kernel/results/fedora-35-x86_64/goffice-0.10.50-2.fc35/goffice-devel-0.10.50-2.fc35.x86_64.rpm

this is a regular file, not a directory
opened with ACCESS_MASK: 0x00120089

that is:

SEC_STD_SYNCHRONIZE|
SEC_STD_READ_CONTROL|
SEC_FILE_READ_ATTRIBUTE|
SEC_FILE_READ_EA|
SEC_FILE_READ_DATA

so indeed, this is being opened *without*
SEC_FILE_WRITE_DATA|SEC_FILE_APPEND_DATA
so smbd is correct in returning ACCESS_DENIED
to an SMB2_FLUSH call.

Looks like this is a client bug, in that it
is passing a Linux fsync(fd) call directly
to the SMB2 server without checking if the
underlying file is open for write access.

In this case, the SMB2 client should just
return success to the caller, as any SMB_FLUSH
call will always return ACCESS_DENIED on a
non-writable file handle, and according to
Linux semantics calling fsync(fd) on an fd
open with O_RDNLY should return success.

Steve, over to you :-).

Jeremy.

Re: Permission denied when chainbuilding packages with mock

[Julian Sikorski]

W dniu 07.11.2021 o 22:49, Jeremy Allison pisze:
> On Sun, Nov 07, 2021 at 01:44:53PM -0800, Jeremy Allison wrote:
>> On Sun, Nov 07, 2021 at 10:10:17PM +0100, Julian Sikorski wrote:
>>>
>>> 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.
> 
> If this is actually what is happening, Samba is implementing the
> Windows semantics, and not the Linux ones (as we should). From
> the Microsoft MS-SMB2 spec:
> 
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/026984f6-38af-4408-8200-50557eb0a286 
> 
> 
> --------------------------------------------------------------------------
> 3.3.5.11 Receiving an SMB2 FLUSH Request
> 10/04/2021
> 
> When the server receives a request with an SMB2 header with a Command value
> equal to SMB2 FLUSH, message handling proceeds as follows:
> 
> The server MUST locate the session, as specified in section 3.3.5.2.9.
> 
> The server MUST locate the tree connection, as specified in section 
> 3.3.5.2.11.
> 
> Next the server MUST locate the open being flushed by performing
> a lookup in the Session.OpenTable, using the FileId.Volatile of the
> request as the lookup key. If no open is found, or if Open.DurableFileId
> is not equal to FileId.Persistent, the server MUST fail the request
> with STATUS_FILE_CLOSED. Otherwise, the server MUST locate the Request
> in Connection.RequestList for which Request.MessageId matches
> the MessageId value in the SMB2 header, and set Request.Open to the Open.
> 
> If the Open is on a file and Open.GrantedAccess includes neither
> FILE_WRITE_DATA nor FILE_APPEND_DATA, the server MUST fail the
> request with STATUS_ACCESS_DENIED.
> 
> If the Open is on a directory and Open.GrantedAccess includes
> neither FILE_ADD_FILE nor FILE_ADD_SUBDIRECTORY, the server MUST
> fail the request with STATUS_ACCESS_DENIED.
> --------------------------------------------------------------------------

Hi,

thanks for responding. I am using loglevel 10. I have uploaded the logs 
to my dropbox as they are too big to attach:

https://www.dropbox.com/sh/r4b7q7ti2zmtlu9/AACqFY0FW2oW41Vu8l3nLZJSa?dl=0

The problem happens around 15:45:48. Do the logs show what access mask 
the fsp is being opened with you requested?
I am using quite an old samba server (4.9.5+dfsg-5+deb10u1) due to the 
fact that openmediavault is based off debian 10 and there are no samba 
backports available. Having said that, this configuration can work, as 
shown by goffice/goffice-0.10.50-1.fc35.src.rpm rebuild and the fact 
that it was working before for months previously.

Best regards,
Julian

Re: Permission denied when chainbuilding packages with mock

[Jeremy Allison]

On Sun, Nov 07, 2021 at 01:49:47PM -0800, Jeremy Allison wrote:
>>behavior. From 'man 2 fsync':
>>
>>NOTES
>>      On some UNIX systems (but not Linux), fd must be a writable file descriptor.
>
>If this is actually what is happening, Samba is implementing the
>Windows semantics, and not the Linux ones (as we should). From
>the Microsoft MS-SMB2 spec:
>
>https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/026984f6-38af-4408-8200-50557eb0a286
>
>--------------------------------------------------------------------------
>3.3.5.11 Receiving an SMB2 FLUSH Request
>10/04/2021
>
>When the server receives a request with an SMB2 header with a Command value
>equal to SMB2 FLUSH, message handling proceeds as follows:
>
>The server MUST locate the session, as specified in section 3.3.5.2.9.
>
>The server MUST locate the tree connection, as specified in section 3.3.5.2.11.
>
>Next the server MUST locate the open being flushed by performing
>a lookup in the Session.OpenTable, using the FileId.Volatile of the
>request as the lookup key. If no open is found, or if Open.DurableFileId
>is not equal to FileId.Persistent, the server MUST fail the request
>with STATUS_FILE_CLOSED. Otherwise, the server MUST locate the Request
>in Connection.RequestList for which Request.MessageId matches
>the MessageId value in the SMB2 header, and set Request.Open to the Open.
>
>If the Open is on a file and Open.GrantedAccess includes neither
>FILE_WRITE_DATA nor FILE_APPEND_DATA, the server MUST fail the
>request with STATUS_ACCESS_DENIED.
>
>If the Open is on a directory and Open.GrantedAccess includes
>neither FILE_ADD_FILE nor FILE_ADD_SUBDIRECTORY, the server MUST
>fail the request with STATUS_ACCESS_DENIED.
>--------------------------------------------------------------------------

Steve,

I just took a look inside cifsfs and it looks like the smb2_flush()
function is being called on a file descriptor without a check that
the fd is open for writing as far as I can tell. Am I missing such
a check ? Can you investigate to see if this is the case ? This would
also fail against a Windows server too I think.

Jeremy.

Re: Permission denied when chainbuilding packages with mock

[Jeremy Allison]

On Sun, Nov 07, 2021 at 01:44:53PM -0800, Jeremy Allison wrote:
>On Sun, Nov 07, 2021 at 10:10:17PM +0100, Julian Sikorski wrote:
>>
>>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.

If this is actually what is happening, Samba is implementing the
Windows semantics, and not the Linux ones (as we should). From
the Microsoft MS-SMB2 spec:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/026984f6-38af-4408-8200-50557eb0a286

--------------------------------------------------------------------------
3.3.5.11 Receiving an SMB2 FLUSH Request
10/04/2021

When the server receives a request with an SMB2 header with a Command value
equal to SMB2 FLUSH, message handling proceeds as follows:

The server MUST locate the session, as specified in section 3.3.5.2.9.

The server MUST locate the tree connection, as specified in section 3.3.5.2.11.

Next the server MUST locate the open being flushed by performing
a lookup in the Session.OpenTable, using the FileId.Volatile of the
request as the lookup key. If no open is found, or if Open.DurableFileId
is not equal to FileId.Persistent, the server MUST fail the request
with STATUS_FILE_CLOSED. Otherwise, the server MUST locate the Request
in Connection.RequestList for which Request.MessageId matches
the MessageId value in the SMB2 header, and set Request.Open to the Open.

If the Open is on a file and Open.GrantedAccess includes neither
FILE_WRITE_DATA nor FILE_APPEND_DATA, the server MUST fail the
request with STATUS_ACCESS_DENIED.

If the Open is on a directory and Open.GrantedAccess includes
neither FILE_ADD_FILE nor FILE_ADD_SUBDIRECTORY, the server MUST
fail the request with STATUS_ACCESS_DENIED.
--------------------------------------------------------------------------

Re: Permission denied when chainbuilding packages with mock

[Jeremy Allison]

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.

Permission denied when chainbuilding packages with mock

[Julian Sikorski]

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!

Best regards,
Julian