[PATCH] First batch of infrastructure patches for review
by Stef Walter
As was discussed yesterday, I'm working on the sssd dbus infrastructure,
so we can have rich access to sssd information via Dbus. Jakub has been
working on implementing methods that expose that.
These are infrastructure patches, that take the basic DBus support that
sssd has (ie: sbus) and start to mature it so that we can handle things
like properties, NNN-instances of objects, automatic introspection,
object manager, automatic unpacking of args for handlers, and so on.
As I mentioned earlier, some of these concepts may seem foreign, for
example using DBus interface definitions to drive things.
However this has many benefits as we get into implementing more dbus stuff:
* Removes boiler-plate all over the place.
* Lets the compiler check dbus interface implementations and usage.
* Makes it possible to do complex stuff (PropertiesChanged or
ObjectManager) that would otherwise be insane.
I have tried to balance things and not go crazy with changing style all
over the place and keep to the sssd way of doing things most of the time.
Yes, this does involve a codegen, much like flex or bison. It has real
concrete benefits. While it is possible to handcraft the necessary meta
data structs (see patch 0001), you lose compile-time checking and some
robustness.
The codegen generates as little code as possible, and we have tests to
verify that it is correct (thanks Sumit for that idea).
It's important to note that an interface, and an implemented instance of
that interface are two different things.
There's a lot more to do. Next up will be implementing automatic
introspection generation, and property access.
If you prefer to access this as a branch, see:
https://github.com/stefwalter/sssd/tree/dbus-infra
Cheers,
Stef
10 years, 2 months
Fwd: Re: #2257: Setting int option to 0 yields the default value (was: Setting ipa_hbac_refresh=0 yields the default value)
by Dmitri Pal
Are there implication in handling all of them the same new way?
I mean if we assume that by something being equal to 0 we disable it ,
would it cause an undesirable semantic change in some cases?
What about the cases when there is no sense in something being disabled
how we will treat the 0 value then?
For bools it is even more scary. If you say that bool = 0 sets the
default this is a bug because IMO bool = 0 means bool = false and this
is an explicit setting.
Now it is broken but it is consistent. I am concerned that we are
heading into the case when the options will be broken on case by case basis.
-------- Original Message --------
Subject: Re: [SSSD] #2257: Setting int option to 0 yields the default
value (was: Setting ipa_hbac_refresh=0 yields the default value)
Date: Fri, 21 Feb 2014 17:26:06 -0000
From: SSSD <trac(a)fedorahosted.org>
Reply-To: nobody(a)fedoraproject.org
To: undisclosed-recipients:;
#2257: Setting int option to 0 yields the default value
---------------------------------+---------------------------------
Reporter: jhrozek | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: NEEDS_TRIAGE
Component: SSSD | Version: 1.11.4
Resolution: | Keywords:
Blocked By: | Blocking:
Tests Updated: 0 | Coverity Bug:
Patch Submitted: 0 | Red Hat Bugzilla:
Design link: | Design review: 0
Fedora test page: | Chosen:
Candidate to push out: 0 |
---------------------------------+---------------------------------
Feature Milestone:
Release Notes:
---------------------------------+---------------------------------
Comment (by jhrozek):
I found out this is not specific to the single option, but all int and
bool options are affected.
--
Ticket URL:<https://fedorahosted.org/sssd/ticket/2257#comment:1>
SSSD<http://fedorahosted.org/sssd>
System Security Services Daemon
10 years, 2 months
[PATCH] Fix warning unused variable ap_fallback
by Lukas Slebodnik
ehlo,
Yesterday, I spent a lot of time with building sssd in mock and did not notice
warning introduced by myself. I apologize for that.
The variable ap_fallback is used only if sssd is build with journald, but
this variable was declared outside of "#ifdef WITH_JOURNALD"
Patch is attached.
LS
10 years, 2 months
ding-libs: symbol versioning is necessary
by Jan Engelhardt
I had libref_array1-0.1.1 and libini_config2-0.6.1 (which were built
from ding-libs-0.1.3) installed in the system. Few days ago I built the
new ding-libs-0.3.0.1 source which, among others, yielded a binary
libini_config3-1.0.0.1 package.
After installation of libini_config3, ldd -r
/usr/lib64/libini_config.so.3 yields:
undefined symbol: ref_array_copy (/usr/lib64/libini_config.so.3)
which is a sign that libini_config3 needs a newer libref_array1,
but the package manager did not catch it because the release
following commit 8c201905d5f0720b62d036eb2308f81f4530cfad
failed to do one of:
(1) changing the SONAME of ref_array, or
(2) using symbol versions
to indicate the new backwards-incompatibility. People, -version-info
1:0:0 => -version-info 2:0:1 is not enough! You must either
(1) -version-info 2:0:0, or
(2) -Wl,--version-script=ref_array.map
10 years, 2 months
GPO ACLs and AGP
by Yassir Elley
Hi,
This email proposes two changes that would allow sssd to correctly support ACL processing on GPO objects.
In addition to various other factors, in order for a GPO to be considered applicable to a particular computer target, the GPO object's AD ACL must grant the "ApplyGroupPolicy" right (AGP) to the computer (or, more likely, to a group of which the computer is a member). By default, AD grants the AGP right to the "Authenticated Users" group, which includes both authenticated users and computers. While this group can be placed on AD ACLs (like other groups), it is special in that its membership is supposed to be maintained by the client (not by AD). Additionally, Windows admins can change this default behavior by denying the AGP right to the "Authenticated Users" group, and by granting the AGP right to some other security principal (which could be a "built-in" principal).
Since there has never been a need, SSSD neither maintains an "Authenticated Users" group membership, nor does it cache any Built-in Groups (those whose SIDS are of the form S-1-5-32-*, such as "Administrators", "Users", etc ) returned from LDAP. In order to support the ACL filtering of GPOs described above, the GPO code needs to know which Built-in Groups the computer target is a member of.
I have the following two proposals:
1. I propose that the GPO access-control code (which is executed after a successful pam authentication) should just assume that any user or computer is a member of the "Authenticated Users" group. This would be local to the GPO code, and would therefore have no effect on other SSSD components.
2. I propose that SSSD should no longer filter out built-in groups returned by LDAP, but should rather store them in the sysdb cache, in the same manner as it stores other groups. This would allow the GPO code to seamlessly include the built-in groups in its ACL processing decision. Since we would be storing these built-in groups in the cache, they would be visible to other SSSD components. An alternative would be to have the GPO code interact with AD to determine the computer's group memberships directly (without consulting the cache), but that seems too inefficient.
Comments?
Regards,
Yassir.
10 years, 2 months
[PATCH] DEBUG: Fix crash after fallback from journal log
by Lukas Slebodnik
ehlo,
It was not easy to reproduce this crash in the find-uid-test (log attached)
Here is a backtrace:
#0 0x00007fbeaf7850cf in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=<optimized out>) at vfprintf.c:1635
#1 0x00007fbeaf788b01 in buffered_vfprintf (s=s@entry=0x7fbeafaf51c0 <_IO_2_1_stderr_>, format=format@entry=0x7fbeb119c1a8 "Proc file [%s] is not available anymore, continuing.\n", args=args@entry=0x7fff2d20b668) at vfprintf.c:2328
#2 0x00007fbeaf783ffe in _IO_vfprintf_internal (s=s@entry=0x7fbeafaf51c0 <_IO_2_1_stderr_>, format=0x7fbeb119c1a8 "Proc file [%s] is not available anymore, continuing.\n", ap=0x7fff2d20b668) at vfprintf.c:1289
#3 0x00007fbeaf840a06 in ___vfprintf_chk (fp=0x7fbeafaf51c0 <_IO_2_1_stderr_>, flag=1, format=<optimized out>, ap=<optimized out>) at vfprintf_chk.c:33
#4 0x00007fbeb0d7461a in debug_fn (file=file@entry=0x7fbeb119bfcf "src/util/find_uid.c", line=line@entry=90, function=function@entry=0x7fbeb119c270 <__FUNCTION__.8600> "get_uid_from_pid", level=level@entry=4096, format=format@entry=0x7fbeb119c1a8 "Proc file [%s] is not available anymore, continuing.\n") at src/util/debug.c:257
#5 0x00007fbeb119ae74 in get_uid_from_pid (pid=<optimized out>, uid=uid@entry=0x7fff2d20c9a4) at src/util/find_uid.c:88
#6 0x00007fbeb119b381 in get_active_uid_linux (table=table@entry=0x0, search_uid=search_uid@entry=4294967292) at src/util/find_uid.c:236
#7 0x00007fbeb119b69f in check_if_uid_is_active (uid=uid@entry=4294967292, result=result@entry=0x7fff2d20ca67) at src/util/find_uid.c:333
#8 0x00007fbeb119a9ab in test_check_if_uid_is_active_fail (_i=<optimized out>) at src/tests/find_uid-tests.c:58
#9 0x00007fbeb054887e in tcase_run_tfun_fork (i=0, tfun=0x7fbeb14a0300, tc=0x7fbeb14a00a0, sr=0x7fbeb14a0390) at check_run.c:396
#10 srunner_iterate_tcase_tfuns (tc=0x7fbeb14a00a0, sr=0x7fbeb14a0390) at check_run.c:181
#11 srunner_run_tcase (tc=0x7fbeb14a00a0, sr=0x7fbeb14a0390) at check_run.c:313
#12 srunner_iterate_suites (print_mode=CK_SILENT, tcname=0x0, sname=0x0, sr=0x7fbeb14a0390) at check_run.c:156
#13 srunner_run (sr=sr@entry=0x7fbeb14a0390, sname=sname@entry=0x0, tcname=tcname@entry=0x0, print_mode=print_mode@entry=CK_ENV) at check_run.c:618
#14 0x00007fbeb054892b in srunner_run_all (sr=sr@entry=0x7fbeb14a0390, print_mode=print_mode@entry=CK_ENV) at check_run.c:587
#15 0x00007fbeb119a685 in main () at src/tests/find_uid-tests.c:125
(gdb) l src/util/find_uid.c:88
83
84 fd = open(path, O_RDONLY);
85 if (fd == -1) {
86 error = errno;
87 if (error == ENOENT) {
88 DEBUG(SSSDBG_TRACE_LIBS,
89 "Proc file [%s] is not available anymore, continuing.\n",
90 path);
91 return EOK;
92 }
As you can see in frame 5, it was caused by DEBUG macro. It was strange
because variable path was declared on stack "char path[PATHLEN];"
But it looks like va_list should not be used twice.
http://en.cppreference.com/w/cpp/utility/variadic/va_copy
It is really difficult to reproduce it.
I was not able to reproduce problem on fedora 19 or rawhide
http://koji.fedoraproject.org/koji/taskinfo?taskID=6551367
http://koji.fedoraproject.org/koji/taskinfo?taskID=6551377
and only sometimes on fedora 20 x86_64
http://koji.fedoraproject.org/koji/taskinfo?taskID=6551997 --works
http://koji.fedoraproject.org/koji/taskinfo?taskID=6551349 --doesn't work
Patch is attached.
LS
10 years, 2 months
[PATCH] bashrc_sssd fixes
by Nikolai Kondrashov
Hi everyone,
Attached are several fixes for bashrc_sssd script.
Sincerely,
Nick
10 years, 2 months