[Pkg-xfce-devel] Bug#658284: Bug#658284: xfce4-session: Please review README.Debian

Brian Potkin claremont102 at gmail.com
Thu Feb 2 18:28:35 UTC 2012

On Thu 02 Feb 2012 at 00:22:32 +0100, Michael Biebl wrote:

> The purpose of the plugdev group was previously defined as allowing
> users to mount removable media.
> By granting access to org.freedesktop.udisks* merely by being member of
> that group, those users can now format your system drive. I don't think
> you want that.

It wasn't the best of examples :), but it can tightened to allow
mounting only by specific users or a group.

> And there's a lot of other stuff which won't work if your session is not
> marked as active, like network-manager, packagekit, upower, etc...
> Basically everything which has <allow_active>yes</allow_active> in
> /usr/share/polkit-1/actions/.
> It just isn't feasible anymore to workaround that by creating groups for
> all those different purposes and adding users manually.

The other stuff can also be handled by .pkla files. If unix-group is
used the actions I instanced in my first mail only require the plugdev
and powerdev groups. The netdev group might be the appropriate one for
NetworkManager. Depending on the packages installed, powerdev may or may
not have be created manually. The plugdev and netdev groups are created
by even the most minimal of xfce4 installations. 
> So all in all I don't think it's a good idea to document such a
> workaround as a somehow "blessed" method to deal with this.

This is really the heart of the matter. Given that the README.Debian's
advice on startx no longer fits the present situation, would the xfce
package maintainers feel comfortable with replacing it with something
which at least points to pklocalauthority(8)?

> For now, I'd just recommend to use a supported display manager.
> The problem with startx resp. the 90consolekit script is, that it is run
> as unprivileged user and CK no longer trusts this context.
> That said, I don't think this problem is unfixable. I guess what it
> requires is that the PAM stack is setting up the right context so CK can
> trust it.

Is that a reference to using

   session optional	pam_loginuid.so

in /etc/pam.d/common-session? That also works me and has the advantages
of being a single configuration change and having a Consolekit session
marked as 'active = TRUE' and 'is-local = TRUE'. I'd be supportive of
including a description of this method in README.Debian if it were to
help a significant number of startx users.

More information about the Pkg-xfce-devel mailing list