PolKit and KDE4_AUTH_POLICY_FILES_INSTALL_DIR

[Alexander Neundorf]

Hi,

On Wednesday 16 February 2011, John Layt wrote:
> Hi,
>
> I've hit an issue with polkit-qt and the KDE4_AUTH_POLICY_FILES_INSTALL_DIR
> variable where the variable seems to always be set to the polkit-qt path
> and your $KDEDIR path is ignored.

This was a longer discussion with Dario end 2009, full details are here:
http://markmail.org/message/oqn73yj6lfyudlue


> The problem comes if you do not build kdesupport/polkit-qt yourself and
> instead try to rely on the system polkit-qt packages.  This causes
> kde4_install_auth_actions() to try install the actions to the system path
> instead of your $KDEDIR path.  If you build polkit-qt yourself then your
> polkit-qt install path is $KDEDIR so there are no problems.
>
> Additionally, if you try to override the path then kdelibs ignores both the
> env var value and the cmake -D value, 

Hmm, yes, I see. This is in kdelibs/auth/ConfigureChecks.cmake:

set(KDE4_AUTH_POLICY_FILES_INSTALL_DIR ${POLKITQT-1_POLICY_FILES_INSTALL_DIR}
 CACHE STRING "Where policy files generated by KAuth will be installed" FORCE)


The FORCE makes it impossible to override using -D or something. It will 
always be set to the value used in this line, i.e.  
${POLKITQT-1_POLICY_FILES_INSTALL_DIR}.

Dario, is this what you wanted ?

> and the other modules ignore the env var but pay attention to the cmake -D,

I.e. cmake -DKDE4_AUTH_POLICY_FILES_INSTALL_DIR=/some/where you mean right ?
Yes, that's intentional. 
The compromise back then was to put the variable 
KDE4_AUTH_POLICY_FILES_INSTALL_DIR at least in the cache, so users (people 
building KDE modules) have at least the chance to change the value via make 
edit_cache or cmake-gui (or -D).

> giving a somewhat unsatisfactory temporary hack around the problem.
>
> Is this the intended behaviour, or is it a bug?  If intended then why have
> the KDE4_AUTH_POLICY_FILES_INSTALL_DIR variable at all?
>
> The consequence is we are effectively telling anyone who wishes to build
> any module of KDE that they must always build polkit-kde themselves (and
> possibly kdelibs?).  I can see this might be needed if you want to test
> things that rely on polkit, but it is not exactly newbie friendly and will
> need to be documented if true.
>
> There is a warning message displayed in the kdelibs cmake about it:
>
>     WARNING: Installation prefix does not match PolicyKit install prefixes.
>     You probably will need to move files installed in
> POLICY_FILES_INSTALL_DIR and by dbus_add_activation_system_service to the 
> prefix

Ok, there is a bug in the warning message, at the end should be the directory 
where PolkitQt-1 has been found.


> I'm sorry, but I can't understand what that means, a newbie has even less
> hope.  It's also only displayed in kdelibs which is of no use when trying
> to build kde-workspace.
>
> I'm guessing here, but I assume that for security reasons polkit-qt only
> reads action files from the one path it was given at build
> (AUTH_POLICY_FILES_INSTALL_DIR), hence anything installed into $KDEDIR
> would be ignored by a system install of polkit-qt, so by ignoring $KDEDIR
> we're trying to be helpful?  If that's the case, that seems like the less
> safe option to me.  Surely it would be better to install to the requested
> inactive path and leave it to the dev to sort out afterwards?  It seems
> less likely to cause security problems, and in most cases the dev isn't
> even interested in the code that needs the actions file.
>
> The way I think this should work is:
> 1) Use KDE4_AUTH_POLICY_FILES_INSTALL_DIR if specified, else use KDEDIR
> 2) If path different from polkit-qt AUTH_POLICY_FILES_INSTALL_DIR then
> display an appropriate warning
> 3) Install to the requested location, it's then up to the dev to fix if
> needed by either moving the files or by building polkit-qt themselves.

Dario ?

Alex