sw-notify-send -- a system-wide notify-send wrapper
===================================================

Please note that this project is no longer maintained.

Please use libtinynotify-systemwide & tinynotify-send instead.


A quick introduction
--------------------

Even wondered why libnotify doesn't support sending notifications using
user other than the one running the notification daemon? I have done
that many times too, and never found an answer. This is why I have
created this tiny tool.

sw-notify-send stands for 'system-wide notify-send', and that means it
is a wrapper for the `notify-send` tool, allowing to use it using
another user account (and send notifications out of the particular
session running the daemon).


System requirements
-------------------

* The `proc` library (which can be found in the procps package),
* [libtinynotify][1] with `--enable-cli`.

[1]:https://github.com/mgorny/libtinynotify/

How to use
----------

sw-notify-send is only a dumb wrapper for notify-send. Thus, it doesn't
take any arguments of its' own and passes all of them to notify-send.
Thus, to use it you simply replace `tinynotify-send` with `sw-notify-send`
in your shell script (or command line, or wherever you're going to use
it).

In other words, you use it like:

	sw-notify-send 'Test' 'Hello world!'

Simple, isn't it?

And as you might have expected, sw-notify-send requires a lot
of privileges (details below). Thus, if run using a regular user, it
will most certainly notice only his own notification daemon. To get real
system-wide notifications, you need to run sw-notify-send using
the superuser account (e.g. through sudo).


Technical details
-----------------

sw-notify-send simply iterates over all running processes (using
the `/proc` filesystem) looking for anything looking like
a DBus session bus. And by 'looking like', I mean having `dbus-daemon`
as the basename and `--session` among its arguments.

For every one it finds, it tries to grab the access details and send
the notification. It tries to preserve DISPLAY and XAUTHORITY, and calls
`setresuid()` to get the identity of that user -- and that should be enough
for dbus to let us in.

In addition to that, sw-notify-send also supports having
the notification daemon running in a chroot. If it founds one doing so
(looking at the `root` procfs entry), it calls `chroot()` to enter
the chroot.

<!-- vim:se syn=markdown : -->