[eeps] EEP: safe file operations

[Zoltan Peter Toth]

Hi Raimo,

Both the file operation enhancements, spawn_iodev and {iodev, In, Out}
are targeting the same logic:

We want to be sure that the file that we use (for reading in case of 
file operations,
or for execution in case of open_port) is the same as the one we opened 
before
and performed checks against.
The open_port enhancements (e.g. spawn_iodev) are meant to work only for 
regular files.
(Similar could be done in erl_ddll as well)

Of course I will elaborate these more if the decision is to continue 
this as an EEP.

However, based on what you wrote it seems to me that you don't consider this
as an EEP topic.

So, how to proceed ?
Br,
Zoltan


Raimo Niskanen wrote:
> On Mon, Nov 17, 2008 at 04:08:38PM +0100, Zoltan Peter Toth wrote:
>   
>> Hi,
>>
>> Here comes an EEP for safe(r) file operations.
>> Br,
>>    Zoltan
>>
>>     
>
> Hi Zoltan.
>
> I think our file operation suggestions are good, but just a
> library enhancement should not need an EEP, except when
> one could expect a heavy debate of how to do it (e.g RE).
>
> The spawn_iodev suggestion i understand as unrelated, and 
> also just a library enhancement. Furthermore I suspect
> I do not understand it. Is it about the emulator should
> be able to open other nodes than regular files, or is
> it that it should be possible to open external programs
> that takes their STDOUT and STDERR from already open
> files in Erlang, that is pid() file descriptors (IoDevice).
> I think you need to elaborate on this one.
>
> If they are two unrelated suggestions that could be decided
> on independently there should be two EEPs.
>
>
>
>   
>> EEP: XXX
>> Title: Safe file operations
>> Version: $Revision: 37 $
>> Last-Modified: $Date: 2008-07-11 15:47:13 +0200 (Fri, 11 Jul 2008) $
>> Author: Zoltan Peter Toth [zoltan(dot)peter(dot)toth(at)ericsson(dot)com]
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/plain
>> Created: 17-Nov-2008
>> Erlang-Version: R13B-0
>> Post-History: 17-Nov-2008
>>
>> ----------------------------------------------------------------------
>>
>>
>> Abstract
>>
>>     This EEP proposes additional file operation functions to allow
>>     for concurrency-safe working.
>>
>>
>> Specification
>>
>>     It is proposed that the file operations in module file and filelib
>>     be duplicated to have a version which operates on an already opened
>>     file, using the IoDevice returned from file:open.  
>>
>>     Examples are file:read_file*, file:consult, filelib:file_size,
>>     file_lib:is_*, filelib:last_modified, file:change_*,
>>     file:read_link, file:script, file:write_file*.  Further on,
>>     erlang:open_port could be enhanced to support {iodev, In, Out}
>>     (enhancing {fd, In, Out}) or {spawn_iodev, IoDevice} (enhancing
>>     {spawn, Command}).  
>>     
>>     For the implementation of these functions in GNU libc, see
>>     chapter 2.2 in [1], particularly the table 2.2.1.  
>>
>>
>> Motivation
>>
>>     The current function implementations mentioned above cannot
>>     protect against a case when
>>         1. a file is opened by application 1
>>         2. something is checked on it (access rights, size, checksum,...)
>>         3. the file is closed
>>         4. it is changed by application 2
>>         5. it is opened again by application 1 assuming that the checks
>>         performed in step 2 would still succeed.  
>>
>>
>> Rationale
>>     The proposed change would be useful both for implementing secure
>>     file operations (i.e. to prevent security holes),
>>     as well as concurrency-safe applications like e.g. server side
>>     executables/scripts that access the same files/databases.  
>>
>>
>> References
>>
>>     [1] Defensive Programming for Red Hat Enterprise Linux,
>>         Ulrich Drepper,
>>         http://people.redhat.com/drepper/defprogramming.pdf
>>         
>>
>> Copyright
>>
>>     This document has been placed in the public domain.  
>>
>>
>> Local Variables:
>> mode: indented-text
>> indent-tabs-mode: nil
>> sentence-end-double-space: t
>> fill-column: 70
>> coding: utf-8
>> End:
>> 
>>     
>
>   
>> _______________________________________________
>> eeps mailing list
>> eeps@REDACTED
>> http://www.erlang.org/mailman/listinfo/eeps
>>     
>
>