As the filename is now a stringshare, also make sure virtual
files use stringshares for the filename! Also when unmapping
we still need to test whether it is copied or not as unmap
will break on less tolerant architectures.
@fix T6449
since we have a sigbusd handler that flags an eina file with io errors
it has to walk the file cache and every file... taking locks. if those
locks were taking already in the current thread the sighandler was
called in... we'd deadlock. since this basicallly never happens (when
do we see i/o errors really? not much)... we never saw this as it'd
also reauire this race condition to happen too. but it is a problem
waiting to happen. this fixes that by moving to recrusive locks.
@fix
Summary:
This was causing problems on non-Linux architectures as eina_file_real_close unmapped not mapped data. Added a "copied" flag to Eina_File which is set on eina_file_virtualize (on copied data), and tested for when eina_file_real_close does the unmap. I'm surprised Linux allowed this. Certainly all of the BSDs crashed with the previous behaviour.
@fix T5479
Test Plan: Example inlcude Rage and Enlightenment Thumb on BSD systems which use eina_file_virtualize with emotion to obtain album artwork.
Reviewers: raster, cedric, jpeg
Reviewed By: jpeg
Maniphest Tasks: T5479
Differential Revision: https://phab.enlightenment.org/D5006
so we copy data to an UNALINED memory address (just after whatever
string we packed on the end of the eina file struct header). this is
bad. especially for non-intel architectures. this forces a 16 byte
alignment which should cover us.
@fix
I'm not sure about the rest of this code, so it's possible that
the index is increased even if it shouldn't. But I've observed
a crash at this line, apparently when reaching the end pointer.
Summary: CreateFileMapping return handle. The handle before use is always closed. This handle can be immediately closed after use.
Reviewers: cedric, raster, vtorri, rimmed, an.kroitor, FurryMyad, NikaWhite
Reviewed By: raster
Subscribers: artem.popov, cedric, jpeg
Tags: #windows
Differential Revision: https://phab.enlightenment.org/D4699
file != NULL does not mean it's valid. Since Eina_File is
a basic eina type a magic check is still better than nothing.
It can avoid doing eina_file_dup() on a closed file for instance.
This "fixes" a crash in eina_file_close with invalid files.
Now I can go hunt the root cause...
If the template is a path, mkstemp and mkdtemp would fail
miserably as they would try to create a file inside
/run/user/1000//path/to/file.XXXXXX even if the path did not
exist.
This patch fixes that by creating temp files inside the sys temp
dir iif the templatename is just a basic name without path
separator.
@fix
This reverts commit 22b45f220c.
eina_file_cleanup always does an eina_tmpstr_del. This is now capable of doing
double or even triple free in some case.
Summary:
Apparently eina_tmpstr_strlen counts the null character as well. This
doesn't follow how strlen works, as the latter excludes it from the count.
This resulted in mistreatment of the string in _eina_file_escape, with
tmp_str paths that had "../".
This fix will do for now, but it is advised that we avoid using
eina_tmpstr_strlen, to prevent such confusions in the future.
Test Plan:
The following lines will throw a valgrind 'invalid read of size 1' error
prior this fix:
char *path = "home/mydir/../myfile";
Eina_Tmpstr *tmp_str = eina_tmpstr_add(path);
char *ret_path = eina_file_path_sanitize(path);
@fix
Reviewers: cedric, stefan_schmidt
Subscribers: tasn, cedric
Differential Revision: https://phab.enlightenment.org/D1929
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This reverts commit f52f562891.
This is reverted because it breaks eina_file_path_sanitize when using
"/../" in paths, for example:
eina_file_path_sanitize("/home/../mydir/myfile")
returns: "/mydir/myfili"
What invalid read size does this fix? Why was no test case specified?
Anyway, this change affects too much code to leave it in like this.
There seems to be an intent to check that UID==EUID
before calling getenv to get the temp directory.
But that was lost in commits 61478af3a6 and
then in e105abc99e.
XDG_RUNTIME_DIR gives us a nice securty benefit by only allowing the
same user to read wand write files.
In some configuration this is problematic though. If one looks at the
bug report this fixes for example you can see that there are build
scripts that use a special build user.
The way this has always worked on unix is that you can define your
own tempdir with TMPDIR. When I was making the original change towards
XDG_RUNTIME_DIR I expected some trouble with it but it worked quite
well so far.
To avoid breaking scripts out there and maybe configurations we
haven't tested yet give TMPDIR precedence over XDG_RUNTIME_DIR.
Fixes T1766
umask() sets the permissions of the file to read-only on Windows
(see umask documentation on MSDN).
This breaks the creation of .edj file (epp needs to modify the
created file).
Anyway, on Windows, permissions should be given to anybody.
@fix
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Instead using $TMPDIR and falling back to /tmp we now try $XDG_RUNTIME_DIR
first.
"$XDG_RUNTIME_DIR defines the base directory relative to which user-specific
non-essential runtime files and other file objects (such as sockets, named
pipes, ...) should be stored. The directory MUST be owned by the user, and
he MUST be the only one having read and write access to it. Its Unix access
mode MUST be 0700."
While improving our security by isolating these files from other users this
has the potential to break things. I have not seen any breakage in testing
but keep this commit in mind if something strange happens on your system.
Summary:
when dest directory is protected from writing success value was returned
@fix
Reviewers: seoz, cedric, Hermet
Reviewed By: Hermet
Subscribers: cedric, reutskiy.v.v
Differential Revision: https://phab.enlightenment.org/D1366
We where inserting the pointer data instead of the pointer, leading to
unaligned access on Sparc (Thanks Lutin to report it and Debian tools/infra
to help us catch it) and also a memory leak.
this makes efl ignore certain env vars for thnigs and entirely removes
user modules (that no one ever used) etc. etc. to ensure that *IF* an
app is setuid, there isn't a priv escalation path that is easy.
Before this patch, we were unconditionnaly destroying the Eina_File if that one
did change on disk. We also make sure that we remove the right entry from the cache
if the file did change there.