Files.newDirectoryStream(Path, LinkOption...)

Martin Buchholz martinrb at google.com
Wed Feb 12 15:30:00 PST 2014


Colin, I think it's too hard in Java.

To give proper threat perspective, imagine disgruntled employee leaves
company but leaves process running that randomly toggles files between
symlinks to / and real subdirectories.  Can you guarantee that you will
never check-then-act racily and follow a symlink to / while removing the
user's home directory?


On Wed, Feb 12, 2014 at 2:55 PM, Colin Decker <cgdecker at google.com> wrote:

> I was running into this issue trying to implement a secure recursive
> delete method that can guarantee it won't follow symbolic links to
> directories, so I'd say FileSystemProvider-level support for recursive
> delete would be even better (though even then, I think it would be good to
> have this). Interestingly, it seems that it's possible to implement this
> provided that the file system supports SecureDirectoryStream, by opening a
> SecureDirectoryStream to the working directory and then using that to open
> a SecureDirectoryStream to the path with NOFOLLOW_LINKS.
>
>
>
> On Wed, Feb 12, 2014 at 4:50 PM, Alan Bateman <Alan.Bateman at oracle.com>wrote:
>
>> On 12/02/2014 17:45, Colin Decker wrote:
>>
>>> Why is there no method for opening a DirectoryStream that allows
>>> NOFOLLOW_LINKS? SecureDirectoryStream has such a method, but ironically it
>>> isn't possible to get a SecureDirectoryStream in the first place without
>>> the possibility of following a symbolic link. Any number of other methods,
>>> including those for reading attributes and opening streams/channels, do
>>> allow NOFOLLOW_LINKS, so why not newDirectoryStream?
>>>
>> This was deliberate at the time to keep the newDirectoryStream methods
>> simple and because NOFOLLOW_LINKS wasn't widely supported (this is also why
>> SecureDirectoryStream is not required to be supported). So yes, this means
>> you will always follow links when obtaining the initial
>> SecureDirectoryStream. It is probably an area that should be looked at
>> again in the future although the support for NOFOLLOW_LINKS or equivalent
>> is still a bit sparse.
>>
>> -Alan.
>>
>
>
>
> --
> Colin Decker | Software Engineer | cgdecker at google.com | Java Core
> Libraries Team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20140212/51cfdd05/attachment.html 


More information about the nio-dev mailing list