RE: Execute only permission issue with client

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Tue, Jul 1, 2014 at 3:10 PM, Frank Filz <ffilzlnx@xxxxxxxxxxxxxx> wrote:
> > Ok, got another question related...
> >
> > I am running a test that does make the following system call:
> >
> > open("/mnt/foo", O_CREAT | O_TRUNC | O_RDWR, 0);
> >
> > This fails (at least when run from my Fedora 20 client, against either
> Ganesha OR knfsd).
> 
> The test fails, or the open() fails?

The open fails (with EACCESS).

> > When I look at a wireshark trace, I see that the sequence of ops in the
> COMPOUND is:
> >
> > OPEN, ACCESS
> >
> > I would expect the ACCESS to fail since the created file has mode 000.
> 
> According to POSIX, the above open() system call should succeed if a file
> /mnt/foo already exists and that file's ACL/mode is compatible with the
> requested O_RDWR access pattern. The open() should also succeed if a file
> /mnt/foo does not exist, and your process has valid file create permissions
> for the directory /mnt (it will create a file /mnt/foo with the mode bits set to
> 0).
> 
> In both cases, the result should be a valid file descriptor that can be used for
> reading and writing.

Right, and I see that the ACCESS MUST be called AFTER the OPEN (to capture the situation where the file already exists), however, if the file did not exist, the ACCESS fails.

Hmm, the poor client actually has no way to handle this...

And we need the ACCESS call in case the file already existed and was execute only.

I'm not sure the protocol actually allows a proper implementation of this variant of the open system call...

Life would have been a bit easier if the protocol had an ACCESS4_EXECUTE flag for OPEN... But there might still be issues of how to accomplish the permission check and create atomically...

Frank

> --
> Trond Myklebust
> 
> Linux NFS client maintainer, PrimaryData
> 
> trond.myklebust@xxxxxxxxxxxxxxx

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux