Files.newDirectoryStream(Path, LinkOption...)

[Colin Decker]

Martin, I could be wrong but I feel pretty sure right now that if the file
system supports SecureDirectoryStream, it's possible to implement in such a
way that it does guarantee that it will never follow a symlink and delete
the contents of another directory, even in the case where files are
switching between real directories and symlinks--I was specifically
approaching this with that in mind. The recursive delete can throw an
exception if things like that are happening, certainly, but it shouldn't
ever follow a symlink and delete that directory.


On Wed, Feb 12, 2014 at 6:30 PM, Martin Buchholz <martinrb at google.com>wrote:

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


-- 
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/c4a94b7f/attachment-0001.html