Hello,
when doing more tests with TCL, I found a more critical problem.
If I create a directory and just after I create a read only file (mode
0444) inside it, I got a permission denied error. See the attached C
source code. As the previous error, it is random but I always have it
fail before the 10th execution.
I attach the network traffic but it seems that the problem is again in
the client.
Olga, could you test this new testcase on the newest kernel ?
Regards.
Thomas.
On Thu, Jul 21, 2016 at 8:10 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote:
> On Thu, Jul 21, 2016 at 1:14 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>> On Thu, Jul 21, 2016 at 04:54:36PM +0200, Thomas Gambier wrote:
>>> On Mon, Jul 18, 2016 at 4:09 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>>> > On Mon, Jul 18, 2016 at 03:44:48PM +0200, Thomas Gambier wrote:
>>> >> Hello,
>>> >>
>>> >> thanks for your answer. See my comments below.
>>> >>
>>> >> On Wed, Jul 13, 2016 at 3:26 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>>> >> > On Mon, Jul 11, 2016 at 07:40:11PM +0200, Thomas Gambier wrote:
>>> >> >> Hello,
>>> >> >>
>>> >> >> I just discovered a problem with NFSv4 file system. I was using TCL
>>> >> >> scripts that were doing some file manipulation (mkdir, copy, ...) on
>>> >> >> my NFSv4 file system and sometimes the scripts failed with "permission
>>> >> >> denied" error.
>>> >> >>
>>> >> >> I ran strace and I found that the system call returning the error was:
>>> >> >> open("d1/in.txt", O_WRONLY|O_CREAT|O_TRUNC, 0100444) = -1 EACCES
>>> >> >> (Permission denied)
>>> >> >
>>> >> > Is that even allowed? The open(2) man page says posix leaves behavior
>>> >> > in that case unspecified, and doesn't say anything I can find about
>>> >> > Linux behavior in this case.
>>> >> >
>>> >> You're right. I will send a mail to TCL mailing list to know why they
>>> >> put this flag in the open call.
>>> >>
>>> >> > I guess it would be nicer for client or server to do something
>>> >> > predictable, though. First steps might be to confirm what happens other
>>> >> > filesystems, then do a network trace (watch the traffic in wireshark) to
>>> >> > see if it's the client rejecting this open, or the client passing
>>> >> > through that bit in the mode and the server returning the error.
>>> >>
>>> >> I agree. For other filesystem, I only tested with ext4 which works
>>> >> fine. Let me know if you want me to test specific filesystems.
>>> >>
>>> >> I attach the wireshark capture of a test with 8 open call working fine
>>> >> and the 9th one failing. For me, it seems the activity on the network
>>> >> is exactly the same for the failing case (same call from client to
>>> >> server and same answer from server to client). It would mean that the
>>> >> client itself is messing things up...
>>> >
>>> > Agreed, sounds like the client's only deciding to fail the open after
>>> > the OPEN call to the server succeeds.
>>> >
>>> > Unfortunately, the client open logic is (necessarily) pretty
>>> > complicated--a few minutes digging around wasn't enough for me to figure
>>> > uot where the error's coming from.
>>> >
>>>
>>> I'm not sure if I can help... I don't know the NFS source code at all.
>>> I can do more tests if you need, though.
>>
>> It doesn't look like a high priority based just on what we know
>> (slightly odd behavior in an undefined case), so I think we'll just have
>> to leave it at that until somebody gets curious. Thanks for the report.
>>
>
> Hi Thomas,
>
> I don't know exactly what was fixed or when but I thought I'd note
> that I don't see the problem on the upstream 4.7-rc7 but I can
> reproduce the problem on RHEL7.2 kernel.
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/stat.h>
int main()
{
int fd, i, result;
char filename[100];
char dirname[100];
for (i=0; i<1000; i++)
{
sprintf(dirname, "d%d", i);
sprintf(filename, "d%d/testfile.txt", i);
result = mkdir(dirname, 0755);
if (result < 0)
{
perror("Mkdir failed\n");
fprintf(stderr, "Error creating %s\n", dirname);
return 1;
}
//sleep(1);
fd = open(filename, O_WRONLY|O_CREAT|O_TRUNC, 0444);
if(fd < 0)
{
perror("Open failed\n");
fprintf(stderr, "Error creating %s\n", filename);
return 1;
}
}
return 0;
}
Attachment:
NFS_traffic2.pcapng
Description: Binary data
