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

Re: [nfsv4] proposed slight change to ACCESS and wordsmithing changes for chapter 18 (thru the LINK operation)



>
> On Mon, 2008-04-07 at 15:00 -0700, Mike Eisler wrote:
>> http://eisler.com/nfsv4-wg/2008-04-07-ch18_thru_link.html
>>
>> The slight change to ACCESS is require that servers only
>> look at the execute bits when determining if a user can execute
>> the file. The rationale is in the proposed changes.
>
> While the rules seem sane enough for POSIX clients and server, I'm still
> a tad confused. Don't these rules mean that Windows servers may never
> set ACCESS4_EXECUTE because NTFS doesn't support execute mode bits?
>
> If so, won't that cause an interoperability issue?

After doing chmod a-x Makefile from cygwin,
the Windows XP properties window shows

Permissions for Eisler, Michael
                      Allow Deny
Full Control
Modify
Read & Execute
Read                    x
Write
Special Permissions     x

--------------

So I think we are fine. If anything NTFS is more NFS ready in
this regard than POSIX file systems, because it makes the sane
observation that if one has execute rights, one has read rights,
unlike POSIX.

But let's say a file system doesn't have execute permission bits.

If the file has a .exe extension (or other executable
extension) the server probably returns
ACCESSx_EXECUTE. So with a mild change in the proposed text,
Windows client to Windows server interoperability is not an issue.

Windows client to POSIX server interoperability isn't an issue either.

So it is POSIX client to Windows server interoperability that would
potentially be an issue.

If there are no execute bits, then pre-NFSv4.1, what does
an NFS server return when it receives an ACCESS request
with ACCESSx_EXECUTE in the access field for a file stored on
a file system? The proposal is for the server to clear
ACCESSx_EXECUTE from the supported field of the result which
was the implied behavior for NFSv4.0 too. The proposal
states that ACCESS4_EXECUTE is not set in the supported
field of the reply, then the client has to send ACCESS with
ACCESS4_READ, and live with issues the preamble to the rules
discusses.

If this causes problems for pre-NTFS Windows filesystems, like
FAT then I can live with it.


_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4