cwrap test roadblock
by Nikolai Kondrashov
Hi everyone,
While trying to arrange running sssd under cwrap in "make check" I came upon
this roadblock:
There doesn't seem to be a way to make libnsss_sss use server sockets in
non-default location at runtime, only at build time. And it seems that doing
it at runtime would be a security issue.
That means that we can't include tests involving libnss_sss into "make check",
as that is not guaranteed to be invoked on a build with a special location
where the current user can write to.
This leaves us with being able to run these tests under CI only, which can
arrange for special configure options and thus locations.
Could there be another way? Am I missing something?
Thanks a lot for any suggestions!
Nick
9 years, 4 months
[PATCH] sss_client: Return a different error when sssd is not running
by Lukas Slebodnik
ehlo,
The sss nss plugin is present in nsswitch by default due to glibc caching
and problem with long living applications (e.g. GNOME). The SSSD nss plugin
should behave as if it was functioning but had no data even thought sssd is not
running. The errors have to be passed from nss plugin up to the user with
minimal moidiffication.
Resolves:
https://fedorahosted.org/sssd/ticket/2439
How to test:
* minimal installation of fedora/rhel7 should already contain sss
in /etc/nsswitch.
* grep sss /etc/nsswitch
* package sssd-client should be installed on machine
* test glibc functions whether ther return 0 for nonexisting group.
(there is attached file sssd_error_code_test.c for lazy people :-)
* the same return code should be with and without sss in /etc/nsswitch.conf
authconfig --disablesssd --update
authconfig --enablesssd --update
NOTE: I just patched functions which returned non-zero return code with stopped
sssd, because initgroups, getservent_r, getnetgrent_r returned 0 even with sss
in nsswitch.
There is also alternative solution from Stephen Gallagher which I found after
writing my patch :-)
https://bugzilla.redhat.com/attachment.cgi?id=788567
LS
9 years, 4 months
[PATCH] simple access provider - don't fail on non-existing objects
by Pavel Reichl
Hello,
I noticed that if using simple access provider and having non-existing
group or user in access/deny list then access will be denied and "su:
System error" will be printed.
I think it's OK to simply skip non-existing objects on allow_list.
I'm not so sure what to do in case of deny lists. Should we also just
skip them or should we deny the user and print more appropriate message
("su: Permission denied")?
Thanks,
PR
9 years, 4 months
[PATCHES] Merging INI snippets
by Dmitri Pal
Hello,
Extensive travel in recent months allowed me to finish this code.
Here is the updated design:
https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge
Patches:
0001 - Fix in case the Ref array is empty and we need to print/debug it
0002 - Declaration of the new function to do access checks
0003 - Big patch with core functionality
0004 - Updated access check code to use new internal access control function
0005 - File with expected output for unit test validation
0006 - Makefile and related changes to start building new code
No rush, take your time. :-)
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
9 years, 4 months
Request for review of the new INI interface
by Dmitri Pal
Hello,
I have been working on an interface to modify configuration file (yes
alternative to augeas) as promised.
INI supports multi valued keys so the interface needs to be able to
manage duplicates.
The attached header file contains the prototype of the interface.
I have implemented value management and about to do the section
management. That part would be quite simple.
Before I polish everything up, hook together and start sending patches I
wanted to make sure the interface is OK and is not missing anything.
I was not sure how much of the design page is needed.
I will probably create one based on this thread with a pointer to header
file.
The assumption is that:
- the caller will read an existing configuration object from a file or
create a configuration object himself. These calls are alreadyavailable
for some time.
- the caller will then add/updated/delete the configuration object as he
sees fit. This is this interface.
- the caller then will call already existing serialization function that
will return a simple buffer object that will contain a serialized
configuration ready to be stored in a file.
- the caller can use simple buffer methods to write content of the
buffer to a file descriptor or just create a file (FILE *), get the
serialized buffer and write to that file. It is up to the caller and
there is so far no plan to provide a specific "save function" as it is
unclear what would be a good function to have.
Let me know if any of these assumptions wrong.
Please take a look at the file, it has doxygen comments. It is a sanity
check exercise not a thorough review :-).
The comments refer to collection interface so I included it too for
easier reading.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
9 years, 4 months