[PATCH] IPA: Return and save all SELinux rules in the provider
by Jakub Hrozek
The IPA session code used to download all enabled SELinux rules, but
then filter out those that match to the current user and save only
those. This meant that if a rule was deleted or disabled on the server,
it remained in the cache and was still evaluated.
The attached patch changes that behaviour to save all downloaded rules --
if this proves to be slow, we can optimize, for instance in a similar
way HBAC rules are optimized, by falling back to sysdb rules if several
requests arrive within a specified interval. However, we don't use
member/memberof links when saving the SELinux mappings, so the sysdb
write should be reasonably fast.
[PATCH 1/3] IPA: Download defaults even if there are no SELinux mappings
We should always download the defaults because even if there are no
rules, we might want to use (or update) the defaults. Previously, the
defaults were only downloaded when there were some rules on the server.
[PATCH 2/3] SYSDB: Delete SELinux mappings
A sysdb function that can be used to delete SELinux mappings from the
sysdb
[PATCH 3/3] IPA: Return and save all SELinux rules in the provider
https://fedorahosted.org/sssd/ticket/1421
11 years, 9 months
[PATCHES] Modify priority evaluation in SELinux user maps
by Jan Zelený
The functionality is now following:
When rule is being matched, its priority is determined as a combination
of user and host specificity (host taking preference).
After the rule is matched in provider, its host priority is stored
in sysdb for later usage.
When rules are matched in the responder, their user priority is
determined. After that their host priority is retrieved directly from
sysdb and sum of both priorities is used to determine whether to take
that rule into account or not. If more rules have the same priority, the order
given in IPA config is used.
Thanks
Jan
11 years, 9 months
bug in sss_ssh_authorizedkeys
by Franky Van Liedekerke
Hi,
I'm trying to use the experimental feature "sss_ssh_authorizedkeys" on
a up-to-date fedora 17. Now it seems everytime I call that binary, it
returns the non-descriptive error "Not enough memory".
Using my basic C-skills, I downloaded the latest SSSD sources (1.8.4)
and recompiled them myself: the result was the same.
Adding some print-statements, I stumbled upon this function
sss_ssh_get_pubkey_algorithm in src/util/sss_ssh.c:
char *
sss_ssh_get_pubkey_algorithm(TALLOC_CTX *mem_ctx,
struct sss_ssh_pubkey *pubkey)
{
size_t c = 0;
uint32_t algo_len;
char *algo;
SAFEALIGN_COPY_UINT32(&algo_len, pubkey->data, &c);
algo_len = ntohl(algo_len);
algo = talloc_zero_array(mem_ctx, char, algo_len+1);
if (!algo) {
return NULL;
}
memcpy(algo, pubkey->data+c, algo_len);
return algo;
}
==> it seems I always end up in the "return NULL" statement, which
seems very weird to me. Current SSH setups can get their authorized keys
from LDAP just fine (using "AuthorizedKeysCommand
/usr/libexec/openssh/ssh-ldap-wrapper" in sshd_config), so my keys are
just fine in LDAP.
I believe the call to SAFEALIGN_COPY_UINT32 is either wrong or has the
wrong arguments, since algo_len is a bizare huge number ...
Trying to change the
return NULL
in
return "ssh-dss
resulted in better effects (but still my key wasn't being accepted,
maybe another issue). The result (a bit obfuscated):
./sss_ssh_authorizedkeys MYUSER
ssh-dss c3NoXXXXXXXXX MYUSER@default
Also, fixing algo_len to "7" seemed to have an effect, but resulted in
another output:
dss AAA c3NoXXXXXXXXX MYUSER@default
So, there seems something wrong here, but I can't figure it out. Any
tips?
Franky
11 years, 9 months
[PATCH] Add missing "%" to specfile
by Jakub Hrozek
I managed to push a wrong patch this morning and broke the upstream
build. I've pushed a one-liner correction to fix it again.
11 years, 9 months
[PATCH] AD: Add missing DP option terminator
by Stephen Gallagher
Pushed to master under the one-liner and unbreak-the-build rules.
One of the option lists was missing a terminator. This worked by luck on
i686 and x86_64 during the build tests, but broke on ARM (and probably
others).
11 years, 9 months