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.
The lock on the main hash was taken to late (after we took the decision
to remove the targeted Eina_File from the cache), this means it was possible
to get an Eina_File from the cache that was going to be removed. This patch
attempt to fix that potential race condition.
Hopefully should fix T461.
Note that eina_file_dup is const from the caller perspective as it
will return a fresh "non const" Eina_File that it will be able to
manipulate as it like.
From glibc mkstemp man page:
In glibc versions 2.06 and earlier, the file is created with
permissions 0666, that is, read and write for all users. This old
behavior may be a security risk, especially since other UNIX flavors
use 0600, and somebody might overlook this detail when porting
programs. POSIX.1-2008 adds a requirement that the file be created
with mode 0600.
More generally, the POSIX specification of mkstemp() does not say
anything about file modes, so the application should make sure its
file mode creation mask (see umask(2)) is set appropriately before
calling mkstemp() (and mkostemp()).
And:
http://cwe.mitre.org/data/definitions/377.html
global_map is set to MAP_FAILED in case of error after mmap.
So, it is initialized to MAP_FAILED and considered valid
otherwise.
So, we don't want to set the map to NULL or even check again NULL.
- Spank Cedric !!!!!
NB: How about we actually fill in "map" after allocation ??
NB: Previously we would malloc "map" and immediately exit without
filling it in, without adding it to the hash....nothing. Just allocate
and get out. Bad Frenchie !!!
Signed-off-by: Chris Michael <cp.michael@samsung.com>