On Mon, 23 Jul 2012 10:15:35 +0200 rustyBSD <rusty...@gmx.fr> said:
> Hi,
> I was told that I have to explain race conditions I found.
>
> I. Copy file bytes
> It concerns 'e_fm_op.c.diff1'. When copying a file, the dest
> file is written with bytes read from source file. It only stops
> when we are at the end of the source file. The problem
> is that you just have to launch a program like this:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> int main()
> {
> char buf[] = "aaaaa";
>
> FILE* f = fopen("file.txt", "wb");
> if (f)
> {
> while(1)
> fwrite(buf, sizeof(buf), 1, f);
> }
> fclose(f);
> }
>
> And then right-click->copy 'file.txt' to another place to cause
> e to indefinitly copy the file (as it never arrives to the end
> of the file).
>
> This point is not discutable. When you copy a file, you ONLY
> must copy n bytes (got by xx.st_size) of source file. It's like
> in file transfer. You get size of file, you split it in blocks and
> send them, and you recalculate the size of the last block to
> have sent exactly the bytes of file. Otherwise, you can flood
> the server.
>
> Quick ex:
> block size -> 100 b
> got file size -> 246 b
> So:
> copy 100 b
> copy 100 b
> copy 46 b
>
> That's it. The file is copied at its original size, even if it has
> changed since the copy has been started.
here i disagree.
1. if we copy a file as its downloading - we want to get the rest of the file
that was appended to after the copy began, if we can.
2. try this with cp. cp behaves like efm. if you're telling me this is a
security issue.. then it's a security issue in cp too.. and been there for a
loooooooooooooong time. :) (i tested it) :)
3. this is only an issue if write rates to file 1 can exceed those to file 2.
4. it cant be going on forever as eventually filesystem fills up and first file
stops filling up. :)
> II. Copy file (2 race conditions)
> When copying a simple file, we do:
> 1. check type of file with stat().
> 2. if dest file doesn't exist
> --> 2.1 if file is a regular file, then copy.
> --> 2.2 ...
> 3. else: ask for overwrite
>
> There is a TOCTOU.
>
> Betwenn 2 and 3, you just have to replace the file by a symlink
> to make the copy copy the file pointed by the link.
>
> Between 1 and 2, you just have to create a symlink to the destination,
> to make the copy copy the source file in the file pointed by the symlink.
>
> You can test:
> - add 'sleep(10);' to the line 1231 of 'e_fm_op.c'
> - copy a file to an empty folder
> - create quickly a symlink in the dest folder with the same name of the
> file which will be copied, pointing to another file
> - wait... and then, check the file pointed by the symlink: its content has
> been overwritten by the source file of the copy
>
> Now, keep the sleep(), apply all patches joined to this mail, and retry.
> You will see that e doesn't copy file, because it detects that file type
> has been changed.
1. your check for "type" wont detect if inode/mode etc. etc. etc. match which
is actually possible given symlink vs dest file. :) so you still have your
"race". it's just a bit more selective
2. the solution to this is actually to unlink then open with O_CREAT|O_EXCL. :)
or.. O_NOFOLLOW (freebsd extn also supported in linux) :) also throw
in O_TRUNC as that's what we want in the above open will fail if someone
slipped in a file or symlink in between
> I was also told that my patches are causing problems and that there are
> no race condition (although if you test, you will see that there are),
> so I'm
> waiting for the response of raster to know what problem(s) it causes.
>
> Maxime.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
