Give default value of O_NOFOLLOW if it is not defined
Alan.Bateman at oracle.com
Wed Jan 4 04:34:16 PST 2012
On 04/01/2012 08:10, Charles Lee wrote:
>> 1. SecureDirectoryStream can't be supported on platforms that don't
>> have O_NOFOLLOW so it means that
>> UnixFileSystemProvider.newDirectoryStream will require to check this
>> before deciding the type of DirectoryStream to return.
> I agree with you. Just simply changing the code in the
> NativeDispatcher's init method will make it happen.
I don't quite understand your comment but the change would be in
UnixFileSystemProvider.newDirectoryStream where it decides whether to
return a UnixDirectoryStream or a UnixSecureDirectoryStream. Where
O_NOFOLLOW is not supported then it will need to return a
>> 2. UnixChannelFactory (which is used by
>> UnixFileSystemProvider.newFileChannel and newAsynchronousFileChannel)
>> will need to fail with UOE if NOFOLLOW_LINKS is specified as an
>> option when opening a file. It's not one of the standard opens and so
>> it's required to be supported, it just happens that all the platforms
>> we currently
> This part of code is a bit tricky. Because !CREATE_NEW &&
> DELETE_ON_CLOSE will still need O_NOFOLLOW. It will be strange for
> user if they do not know the details of implementation but get
> "Unsupported no follow option" only because they use !CREATE_NEW &&
> DELETE_ON_CLOSE. Can I remove the !CREATE_NEW && DELETE_ON_CLOSE ?
There are two places in UnixChannelFactory. First is Flags.toFlags where
UOE can be thrown if NOFOLLOW_LINKS is specified. The second is the
DELETE_ON_CLOSE case. If O_NOFOLLOW is not supported then all I can
suggest is to lstat the file and fail (by throwing an IOException) if
the file is a sym link. Here's how it is worded in the spec:
"For security reasons, this option may imply the
LinkOption.NOFOLLOW_LINKS option. In other words, if the option is
present when opening an existing file that is a symbolic link then it
may fail (by throwing IOException)"
>> 3. Where a FileAttributeView is created that doesn't follow sym links
>> then it's highly platform specific if it can be used to update the
>> attributes of the sym link. This is where
>> UnixPath.openForAttributeAccess is used. I need to double check the
>> javadoc to see how this is specified as I can't recall off-hand if
>> this is treated as an UOE or an IOException (I think the latter).
> From the code and doc, I guess it throws IOException. It is
> interesting that methods in the FileSystemProvider throw UOE because
> not supporting specific attribute view, not include not supporting
> options. Can we add this in the doc? I'd like a UOE been throw in the
> FileSystemProvider if a method is provided a NOFOLLOW_LINKS on the
> platform which is not supported O_NOFOLLOW. This will include all the
> methods which has option as its parameter in the FileSystemProvider.
> What do you think, Alan?
I thought we had wording in the spec to cover this but I'm unable to
find it. As I'm sure you will understand, changing the attributes of a
symbolic link is not very interesting, not feasible in all cases, and
the intention is that a provider is not required to support it. I will
create a bug to get the javadoc clarified on this point. Given that a
provider may support the updating of some attributes, and may not be
able update other attributes then all we can do is have the appropriate
set* method fail with an IOException. For example your platform may
support lchown, in which case it will be able to change the owner of a
symbolic link (not interesting but possible). Given that O_NOFOLLOW is
the issue for you then I think that all issues should be covered by
changing UnixPath.openForAttributeAccess to throw IOException when
followLinks is false.
More information about the nio-dev