Commit Graph

17 Commits

Author SHA1 Message Date
Marco Trevisan (Treviño)
476e33c3f3 gio, glib: Use G_OS_DARWIN for code that is for such environments
While we preserved the COCOA/CARBON cases when specific libraries are
needed.
2022-10-20 03:37:21 +02:00
Philip Withnall
5942cd7984 gio: Add SPDX license headers automatically
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.

This commit was entirely generated using the command:
```
git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #1415
2022-05-18 09:18:52 +01:00
Marc-André Lureau
95c3e28af5 gio: add G_CREDENTIALS_TYPE_WIN32_PID
Credentials are often used to check peer processes details.

With AF_UNIX sockets on Windows, SIO_AF_UNIX_GETPEERPID can
be used to retrive the peer PID.

We will probably introduce more advanced mechanisms later on, though,
but I am not a Windows API expert.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-01-26 18:19:44 +04:00
Ignacio Casal Quinteiro
1848905a99 credentials: support the local peerpid on macos
xucred does not provide the peer pid id, but this can be fetched
from the socket LOCAL_PEERPID option. Note that we only support
it when creating the credentials from a local socket, if
the credential comes from a message over a socket the peer
pid id will not be set and -1 will be returned when trying
to get the pid for the credential.
2022-01-20 10:52:01 +01:00
Dr. Michael Lauer
ec2f60a008 gio: add gcredential support for macOS
[smcv: Apply my review feedback from
<https://bugzilla.gnome.org/show_bug.cgi?id=668866>]

Co-authored-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.gnome.org/GNOME/glib/issues/507
2020-05-07 14:19:16 +01:00
Simon McVittie
05cb229082 GCredentials: Add the concept of credentials that lack the process ID
struct xucred on macOS doesn't have the process ID, only the user ID
and groups.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2020-05-07 14:19:16 +01:00
Simon McVittie
ee502dbbe8 GDBus: prefer getsockopt()-style credentials-passing APIs
Conceptually, a D-Bus server is really trying to determine the credentials
of (the process that initiated) a connection, not the credentials that
the process had when it sent a particular message. Ideally, it does
this with a getsockopt()-style API that queries the credentials of the
connection's initiator without requiring any particular cooperation from
that process, avoiding a class of possible failures.

The leading '\0' in the D-Bus protocol is primarily a workaround
for platforms where the message-based credentials-passing API is
strictly better than the getsockopt()-style API (for example, on
FreeBSD, SCM_CREDS includes a process ID but getpeereid() does not),
or where the getsockopt()-style API does not exist at all. As a result
libdbus, the reference implementation of D-Bus, does not implement
Linux SCM_CREDENTIALS at all - it has no reason to do so, because the
SO_PEERCRED socket option is equally informative.

This change makes GDBusServer on Linux more closely match the behaviour
of libdbus.

In particular, GNOME/glib#1831 indicates that when a libdbus client
connects to a GDBus server, recvmsg() sometimes yields a SCM_CREDENTIALS
message with cmsg_data={pid=0, uid=65534, gid=65534}. I think this is
most likely a race condition in the early steps to connect:

        client           server
    connect
                         accept
    send '\0' <- race -> set SO_PASSCRED = 1
                         receive '\0'

If the server wins the race:

        client           server
    connect
                         accept
                         set SO_PASSCRED = 1
    send '\0'
                         receive '\0'

then everything is fine. However, if the client wins the race:

        client           server
    connect
                         accept
    send '\0'
                         set SO_PASSCRED = 1
                         receive '\0'

then the kernel does not record credentials for the message containing
'\0' (because SO_PASSCRED was 0 at the time). However, by the time the
server receives the message, the kernel knows that credentials are
desired. I would have expected the kernel to omit the credentials header
in this case, but it seems that instead, it synthesizes a credentials
structure with a dummy process ID 0, a dummy uid derived from
/proc/sys/kernel/overflowuid and a dummy gid derived from
/proc/sys/kernel/overflowgid.

In an unconfigured GDBusServer, hitting this race condition results in
falling back to DBUS_COOKIE_SHA1 authentication, which in practice usually
succeeds in authenticating the peer's uid. However, we encourage AF_UNIX
servers on Unix platforms to allow only EXTERNAL authentication as a
security-hardening measure, because DBUS_COOKIE_SHA1 relies on a series
of assumptions including a cryptographically strong PRNG and a shared
home directory with no write access by others, which are not necessarily
true for all operating systems and users. EXTERNAL authentication will
fail if the server cannot determine the client's credentials.

In particular, this caused a regression when CVE-2019-14822 was fixed
in ibus, which appears to be resolved by this commit. Qt clients
(which use libdbus) intermittently fail to connect to an ibus server
(which uses GDBusServer), because ibus no longer allows DBUS_COOKIE_SHA1
authentication or non-matching uids.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1831
2019-10-28 19:56:00 +00:00
Simon McVittie
ef1035d9d8 gcredentialsprivate: Document the various private macros
Signed-off-by: Simon McVittie <smcv@collabora.com>
2019-10-28 19:54:08 +00:00
Sébastien Wilmet
3bf4a720c3 gio/: LGPLv2+ -> LGPLv2.1+
Sub-directories inside gio/ already processed in a previous commit:
- fam/
- gdbus-2.0/ (which contains only codegen/)
- gvdb/
- inotify/
- tests/
- win32/
- xdgmime/

Other sub-directories inside gio/:
- completion/: no license headers
- kqueue/: not LGPL, BSD-style license

https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-29 19:53:34 +02:00
Dan Winship
e8d3f29300 gcredentialsprivate: clarify the USE_FREEBSD_CMSGCRED users
Add comments clarifying what the three non-FreeBSD platforms using
G_CREDENTIALS_USE_FREEBSD_CMSGCRED are.
2015-01-27 07:38:31 -05:00
Peeter Must
4c54b9fe31 gcredentials: Add support for DragonFly
https://bugzilla.gnome.org/show_bug.cgi?id=743508
2015-01-27 07:31:24 -05:00
Patrick Welche
e763d93456 GCredentials: credentials messages are not correctly supported on NetBSD
https://bugzilla.gnome.org/show_bug.cgi?id=735819
2014-09-04 08:26:27 -04:00
Patrick Welche
afce39c228 gcredentials: add NetBSD support
https://bugzilla.gnome.org/show_bug.cgi?id=728256
2014-06-28 14:06:36 -04:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Dan Winship
5a269e5a90 gcredentials: add Solaris support
Based on patches from Igor Pashev.

https://bugzilla.gnome.org/show_bug.cgi?id=705029
2013-10-04 09:51:31 -04:00
Dan Winship
66edac7fb9 gcredentials: add Hurd support
It uses the same system as FreeBSD.

https://bugzilla.gnome.org/show_bug.cgi?id=708265
2013-10-04 09:51:31 -04:00
Dan Winship
cedd697bf8 gcredentials: add internal macros to simplify all the #ifdefs
Rather than having lots of obscure platform-based #ifdefs all over
gio, define some macros in gcredentialsprivate.h, and use those to
simplify the rest of the code.

https://bugzilla.gnome.org/show_bug.cgi?id=701482
2013-10-04 09:51:31 -04:00