Files.newDirectoryStream(Path, LinkOption...)

[Martin Buchholz]

Anyways, recursive directory deletes is a perennial request.  Every OS
since DOS 1.0 has provided a way to do it, and the missing functionality in
Java should be provided someday (jdk9?).  Whether as a wrapper around
SecureDirectoryStream or as a completely native implementation.


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

> About once every three years I see Alan and I always ask him the same
> question,
> "Can you re-implement rm -rf securely and reliably in Java?"
> I think the last time the answer was still "no".
> Alan: Has that changed?
>
> For reliability, there's the problem of non-uniqueness of encoding to
> UTF-16,
> but even for security, I suspect the answer is still "no".  But I have no
> evidence.
>
>
> On Wed, Feb 12, 2014 at 6:00 PM, Colin Decker <cgdecker at google.com> wrote:
>
>> 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/20140219/79b4c579/attachment.html