Re: Permission denied when chainbuilding packages with mock

[Julian Sikorski <belegdol@gmail.com>]

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.
> 
> 
>