[eeps] EEP: safe file operations

[Raimo Niskanen]

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

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB