On 09/26/2011 04:38 PM, Christian Boltz wrote:
Hello,
on Montag, 26. September 2011, Ludwig Nussel wrote:
Christian Boltz wrote:
- start aa-notify using sudo: sudo HOME="$HOME" DISPLAY="$DISPLAY" /usr/sbin/aa-notify -p
For the records: at least HOME=... isn't needed anymore - the upstream version (post-2.7beta2) now sets $HOME correctly.
This is also where I found the bug mentioned above - sudo drops lots of environment variables for security reasons. In practise, it drops too many of them and breaks aa-notify :-(
IOW aa-notify is either broken by design or not meant to be run as user.
I'm not sure about your first option ;-)) but I'm sure the second one doesn't apply.
aa-notify must be started as root (to be able to read audit.log) and then drops the privileges to the user (which is autodetected from the $SUDO_* environment variables when started with sudo) to display the notifications.
Well, to be exact: aa-notify sets its EUID/EGID to the user, switches back to root once per second to check audit.log for changes, and back to the user afterwards and displays a notification if needed. That's still simplified, but you should get the picture.
The interesting part is that it works with sudo on Ubuntu out of the box. They seem to use a less strict configuration that doesn't remove most of the environment variables - for example, $HOME isn't changed to /root on Ubuntu, and $DISPLAY isn't removed - see "sudo env" results from Ubuntu on http://paste.opensuse.org/70652816. This is probably a compile-time config option because using a known- working /etc/sudoers from Ubuntu didn't make it work on my openSUSE 11.4 system.
In other words, it's the usual problem: everything works until I test it. Then I find a bug, find another bug, and then it tends to explode... ;-)
A better solution would be to have a dbus system service that can read the audit log or even subscribe to events directly. The UI would run in the user's session and connect to that system service. To restrict who can read the events policykit can be used.
I don't know much about dbus and policykit, but your idea sounds good.
Unfortunately it also sounds like it would require a (complete?) rewrite of aa-notify, which will need some time...
Not a complete rewrite, just a few fn's to add a new source, and any of the bits around it. This is already done for audit and syslog, and push based alternatives are planned but they won't happen for this release. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org