Time-Based Policies in FreeIPA
by Stanislav Laznicka
Hi,
If you're a member of the FreeIPA-devel mailing list, you may already
know me. I am currently trying to re-introduce the time-based policies
for FreeIPA HBAC Rules to both FreeIPA and SSSD. For some more
information, see the design at
http://www.freeipa.org/page/V4/Time-Based_Account_Policies or read the
whole paper at http://www.fit.vutbr.cz/study/DP/DP.php.cs?id=17185&file=t.
At the moment, I have a prototype solution which is able to decide
whether an HBAC rule should or should not apply based on the time rules
supplied with HBAC rule objects from FreeIPA. See the source code
attached to this mail, if you will. The biggest problem of this solution
is that it is not thread-safe.
It seems to be quite a problem to convert time from a certain time zone
to a different time zone in C and keep it thread-safe. A very simple and
also very ugly solution would be to have a mutex to guard each
localtime() call as well as it should wrap the body of the
time_to_timezone() function from the second patch. This seems rather
unacceptable. The other solution would be to find another way to convert
the time. Currently, there seems to be a C++ Boost solution based on a
.csv file but it is not accepted well
(https://github.com/boostorg/date_time/blob/master/data/date_time_zonespec...).
I was also thinking on using the glibc tzfile parsers
(http://code.woboq.org/userspace/glibc/time/tzfile.c.html#__tzfile_read)
but they too seem rather thread-unsafe and trying to rework it in a
thread-safe manner might be a painful thing to do.
I welcome any suggestions and ideas on the topic as I seem to be quite
stuck here.
Cheers,
Stanislav Laznicka
8 years, 8 months
[PATCHES] DYNDNS: support mult. interfaces for dyndns_iface opt
by Pavel Reichl
Hello,
please see attached patches.
1st patch adds return value ENOENT to sss_iface_addr_list_get() so I can
provide more concrete debug message for missing interface or if
interface is not suitable (missing IP address)
2nd patch:
* I introduced new public function sss_iface_addr_concatenate(), I'm
aware that this function is probably not reusable but I needed to work
around that 'struct sss_iface_addr' in defined in source file only.
* I had troubles with correctly handling creating talloc hiearchy of IPs
of different interfaces. I decided to use first address of first found
interface as a parent talloc context for other interfaces. I attached
talloc report output to illustrate this.
>
> 1.
> full talloc report on 'struct sdap_dyndns_get_addrs_state' (total
> 16 bytes in 1 blocks)
> 2.
> full talloc report on 'struct sdap_dyndns_get_addrs_state' (total
> 376 bytes in 19 blocks)
> 3.
> struct sss_iface_addr contains 360 bytes in 18
> blocks (ref 0) 0xbc0650
> 4.
> struct sss_iface_addr contains 120 bytes in 6 blocks
> (ref 0) 0xbecee0
> 5.
> struct sss_iface_addr contains 80 bytes in 4 blocks
> (ref 0) 0xbeb920
> 6.
> struct sss_iface_addr contains 40 bytes in 2
> blocks (ref 0) 0xbd03f0
> 7.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in
> 1 blocks (ref 0) 0xbd0470
> 8.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1
> blocks (ref 0) 0xbeb9a0
> 9.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1 blocks
> (ref 0) 0xbecf60
>10.
> struct sss_iface_addr contains 120 bytes in 6 blocks
> (ref 0) 0xbd0640
>11.
> struct sss_iface_addr contains 80 bytes in 4 blocks
> (ref 0) 0xbd19a0
>12.
> struct sss_iface_addr contains 40 bytes in 2
> blocks (ref 0) 0xbcfb00
>13.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in
> 1 blocks (ref 0) 0xbed300
>14.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1
> blocks (ref 0) 0xbd1a20
>15.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1 blocks
> (ref 0) 0xbd06c0
>16.
> struct sss_iface_addr contains 80 bytes in 4 blocks
> (ref 0) 0xbd0eb0
>17.
> struct sss_iface_addr contains 40 bytes in 2 blocks
> (ref 0) 0xbd1900
>18.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1
> blocks (ref 0) 0xbec4f0
>19.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1 blocks
> (ref 0) 0xbeca10
>20.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1 blocks
> (ref 0) 0xbe6ae0
>
* I was thinking whether it would be a good idea to handle the case when
processing of interfaces provided in dyndns_iface yields no address at
all by continuing to detect DYNDNS address from LDAP connection?
Thanks!
8 years, 9 months
[PATCH] Fix LDAP AutoFS object class man page
by Robin McCorkell
Fixed default parameter value and description for
ldap_autofs_entry_object_class
---
src/man/sssd-ldap.5.xml | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/man/sssd-ldap.5.xml b/src/man/sssd-ldap.5.xml
index f140908..3436f9e 100644
--- a/src/man/sssd-ldap.5.xml
+++ b/src/man/sssd-ldap.5.xml
@@ -2493,11 +2493,12 @@ ldap_access_filter = (employeeType=admin)
<term>ldap_autofs_entry_object_class (string)</term>
<listitem>
<para>
- The object class of an automount map entry
- in LDAP.
+ The object class of an automount entry
+ in LDAP. The entry usually corresponds to a mount
+ point.
</para>
<para>
- Default: automountMap
+ Default: automount
</para>
</listitem>
</varlistentry>
--
2.4.5
8 years, 9 months
[PATCHES] Wildcard lookups for InfoPipe
by Jakub Hrozek
Hi,
the attached patches implement
https://fedorahosted.org/sssd/ticket/2553.
I'm sorry the patches took so long, but only during testing I realized the
deleting of users not updated by the wildcard lookup is flawed. In case
there were more entries in cache that match the wildcard than the limit
on the wildcard search, we might be deleting legitimate entries that might
contain cached credentials..
What I did instead was never remove any entries during wildcard lookups,
but instead, only return entries that were updated during the wildcard
lookup in the cache_req. That way, stale entries would be deleted by a
direct lookup (maybe as a result of getpwuid when examining a file) or
can be deleted by the cleanup task.
I'm a bit nervous about the LDAP changes, please review ruthlessly :-)
I would also like for the option defaults to be carefully checked during
review.
One question about the by-name-and-domain lookups -- should we check the
domain we receive from the cache_req is the same as we requested?
btw I really like how the cache_req and the infopipe code are structured. It
was quite easy to extend without any hacks.
8 years, 9 months
