Commit Graph

13 Commits

Author SHA1 Message Date
Руслан Ижбулатов
53bd6a359f W32: Add a stat() implementation for private use
This commit adds new W32-only functions to gstdio.c,
and a new header file, gstdioprivate.h.
These functions are:
g_win32_stat_utf8()
g_win32_lstat_utf8()
g_win32_fstat()
and they fill a private structure, GWin32PrivateStat,
which has all the fields that normal stat has, as well as some
extras.

These functions are then used throughout glib and gio to get better
data about the system. Specifically:
* Full, 64-bit size, guaranteed (g_stat() is forced to use 32-bit st_size)
* Full, 64-bit file identifier (st_ino is 0 when normal stat() is used, and still is)
* W32 File attributes (which stat() doesn't report); in particular, this allows
  symlinks to be correctly identified
* Full, 64-bit time, guaranteed (g_stat() uses 32-bit st_*time on 32-bit Windows)
* Allocated file size (as a W32 replacement for the missing st_blocks)

st_mode remains unchanged (thus, no S_ISLNK), so when these are given back to
glib users (via g_stat(), for example, which is now implemented by calling g_win32_stat_utf8),
this field does not contain anything unexpected.

g_lstat() now calls g_win32_lstat_utf8(), which works on symlinks the way it's supposed to.

Also adds the g_win32_readlink_utf8() function, which behaves like readlink()
(including its inability to return 0-terminated strings and inability to say how large
the output buffer should be; these limitations are purely for compatibility with
existing glib code).

Thus, symlink support should now be much better, although far from being complete.

A new W32-only test in gio/tests/file.c highlights the following features:
* allocated size
* 64-bit time
* unique file IDs

https://bugzilla.gnome.org/show_bug.cgi?id=788180
2017-11-01 12:46:38 +00:00
Sébastien Wilmet
f9faac7661 glib/: LGPLv2+ -> LGPLv2.1+
All glib/*.{c,h} files have been processed, as well as gtester-report.

12 of those files are not licensed under LGPL:

	gbsearcharray.h
	gconstructor.h
	glibintl.h
	gmirroringtable.h
	gscripttable.h
	gtranslit-data.h
	gunibreak.h
	gunichartables.h
	gunicomp.h
	gunidecomp.h
	valgrind.h
	win_iconv.c

Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.

Sub-directories inside glib/:

	deprecated/: processed in a previous commit
	glib-mirroring-tab/: already LGPLv2.1+
	gnulib/: not modified, the code is copied from gnulib
	libcharset/: a copy
	pcre/: a copy
	tests/: processed in a previous commit

https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-24 11:58:19 +02:00
Emmanuele Bassi
99ff9bb5e0 Maintain the struct order when initializing
Otherwise it'll break every GLIB_PRIVATE_CALL user.
2015-10-08 12:32:58 +01:00
Matthias Clasen
e0dce8a9ae Export glib_init via GLIB_PRIVATE_CALL
This will be used in the next commit to call glib_init from the
gobject constructor, to ensure proper constructor ordering with
non-GNU libc.

https://bugzilla.gnome.org/show_bug.cgi?id=756139
2015-10-07 23:39:29 -04:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Ryan Lortie
725125aba3 GDir: add some glib-private APIs
Add a simple UNIX-only API that is used to create a GDir object from a
DIR* that is aquired using opendir() or fdopendir().

This makes it possible to use GDir with openat(), which in turn will
allow use of GDir in the existing GLocalFile implementation of
g_file_measure_disk_usage(), avoiding the current MSVC compatibility
problems there.

Also add an API similar to g_dir_open(), but without the GError handling
(since we want to create a better error message from inside of
glocalfile.c).

Thanks to Chun-wei Fan <fanchunwei@src.gnome.org> for portions of this
patch and for reviews.

https://bugzilla.gnome.org/show_bug.cgi?id=707787
2013-09-16 13:38:40 -04:00
Ryan Lortie
7c98844760 various: add missing cases of #include "config.h" 2012-12-06 13:30:31 -05:00
Michael Natterer
49db979922 Revert "gmain: Add private API to create Unix child watch that uses waitid()"
This reverts commit 93bf37ce15.
2012-11-15 15:33:38 +01:00
Colin Walters
93bf37ce15 gmain: Add private API to create Unix child watch that uses waitid()
This avoids collecting the zombie child, which means that the PID
can't be reused.  This prevents possible race conditions that might
occur were one to send e.g. SIGTERM to a child.

This race condition has always existed due to the way we called
waitpid() for the app, but the window was widened when we moved the
waitpid() calls into a separate thread.

If waitid() isn't available, we return NULL, and consumers of this
private API (namely, GSubprocess) will need to handle that.

https://bugzilla.gnome.org/show_bug.cgi?id=672102
2012-11-14 14:11:57 -05:00
Colin Walters
b98a1c8df3 gmain: Handle case where source id overflows
0 is not a valid source id, but for long-lived programs that rapidly
create/destroy sources, it's possible for the source id to overflow.
We should handle this, because the documentation implies we will.

https://bugzilla.gnome.org/show_bug.cgi?id=687098
2012-11-13 11:32:57 -05:00
Colin Walters
d6cbb29f59 CVE-2012-3524: Hardening for being run in a setuid environment
Some programs attempt to use libglib (or even libgio) when setuid.
For a long time, GTK+ simply aborted if launched in this
configuration, but we never had a real policy for GLib.

I'm not sure whether we should advertise such support.  However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.

Better to fix a problem caused by an interaction between two
components in *both* places if possible.

This patch adds a private function g_check_setuid() which is used to
first ensure we don't run an external dbus-launch binary if
DBUS_SESSION_BUS_ADDRESS isn't set.

Second, we also ensure the local VFS is used in this case.  The
gdaemonvfs extension point will end up talking to the session bus
which is typically undesirable in a setuid context.

Implementing g_check_setuid() is interesting - whether or not we're
running in a privilege-escalated path is operating system specific.
Note that GTK+'s code to check euid versus uid worked historically on
Unix, more modern systems have filesystem capabilities and SELinux
domain transitions, neither of which are captured by the uid
comparison.

On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup.  If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use.  Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1

So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.

On some BSD variants, there is a issetugid() function.  On other Unix
variants, we fall back to what GTK+ has been doing.

Reported-By: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>
2012-09-13 18:34:29 -04:00
Ryan Lortie
d86386159d glib worker: move to glib-private framework
Remove the private glib_get_worker_context() symbol and move it over to
using the glib-private stuff like GWakeup is doing.

https://bugzilla.gnome.org/show_bug.cgi?id=657992
2011-09-09 14:32:00 -04:00
Colin Walters
9bf59d4a14 Add glib__private__() API to share between glib,gio; port GWakeup to it
Historically we've added random symbols to the public API with warnings
that they're private; examples are:

glib_gettext(), glib_pgettext()
g_thread_functions_for_glib_use, g_thread_use_default_impl, etc.

And we almost added "GWakeup" to public API just to share between glib and
gio.

This new glib__private__() API exports a hidden vtable, and adds a macro
GLIB_PRIVATE_CALL() that makes it generally convenient to use.

This adds an extremely tiny cost for the double indirection; but it has
the benefit that we don't need to either:

1) compile the code into both glib and gio (like GWakeup), with the
   inefficiency that implies.
2) Export a "do not use this" symbol; the serious problem with this is
   that someone CAN use it pretty easily.  Particularly if we document
   it.  It's far, far harder to peek into a structure without a public
   header file.

https://bugzilla.gnome.org/show_bug.cgi?id=657992
2011-09-09 14:17:08 -04:00