Add LANGUAGE property to LMI_Locale
by Alexander Lakhin
Hello,
It seems that LMI_Locale misses one important property - LANGUAGE.
The property can have value distinct from LC_* and LANG and it is
supported by systemd-localed/localectl.
Is it possible to add it to the LMI_Locale provider?
I would like to propose the attached patch for it or should I file the bug?
Best regards,
Alexander
8 years, 9 months
Polkit-based authorization in OpenLMI providers
by Jan Safranek
Hello,
I've been working on reusing polkit authorization for OpenLMI providers,
which use a DBus service (e.g. NetworkManager, PackageKit, realmd,
systemd, ...).
I've documented the architecture on our wiki [1] and I submitted review
in our review-board. I won't push the patches until we get to an
agreement that it's the way to go and also the implementation is secure
- please review carefully. There are *no* changes needed in our provider
code and/or in the DBus services we work with.
1: https://fedorahosted.org/openlmi/wiki/PolkitAuthorization
2: https://reviewboard-openlmi.rhcloud.com/users/jsafrane/
In short, the concept is similar to Cockpit's reauthorization [3], we
just don't play tricks with user passwords - we don't have one on CIM
provider level. Instead, we register a polkit agent, which bluntly
authenticates every request from polkit in its PAM session.
3: https://github.com/cockpit-project/cockpit/blob/master/doc/reauthorize.md
[Kudos to Cockpit guys, I used their code to implement polkit agent and
helper.]
Just a side note: right now, users with remote CIM access must be
members of 'pegasus' group, otherwise they cannot start a provider. Is
it good or bad? Should _any_ user be able to use CIM by default and let
polkit decide? It's trivial to fix, just set different file/directory
permissions in tog-pegasus.rpm. And there is /etc/Pegasus/access.conf,
which can control access properly if sysadmin wishes, so the question is
just about the default setting.
Jan
9 years, 2 months
lmishell in multiple threads
by Jan Safranek
Hi,
while fixing our openlmi-account tests, I found out that recent lmishell
has problems with accessing one LMIConnection from multiple threads.
For example, test_create() at
https://git.fedorahosted.org/cgit/openlmi-providers.git/tree/src/account/...
- creates one LMIConnection
- creates ~20 threads
- from each thread, issues requests on the LMIConnection and expects an
response.
When using pywbem as backend it mostly works - pywbem creates new TCP
connection for each CIM request. However, with lmiwbem, the tests fails
and quite often it also crashes.
So, how does lmiwbem work when it's accesses in parallel from several
threads? Is it something that should work out of the box or should the
application do some locking? Could you please describe it in our
documentation?
Thanks
Jan
9 years, 5 months
