Files.newDirectoryStream(Path, LinkOption...)

[Martin Buchholz]

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/20140212/be51c7a2/attachment.html