Give default value of O_NOFOLLOW if it is not defined

[Alan Bateman]

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

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

-Alan