Tlog integration and packages
by Nikolai Kondrashov
Hi everyone,
I'd like to continue the discussion of tlog integration, and also present you
the first release of tlog - a development preview, which has the configuration
interface necessary to implement the integration:
https://github.com/spbnick/tlog/releases/tag/v1
You're more than welcome to download RPMs, install, read tlog-rec(8) and
tlog-rec.conf(5), and experiment! Building from the Git tree and the tarball
works as well, if you're so inclined. I'm also attaching those manpages for
convenience.
Here are the integration plans so far, as discussed with Jakub on our
devconf.cz trip meetings and before on the list. Jakub, please correct me or
add details.
* We follow the route similar to that taken by SELinux rule control
implementation [1][2]. I.e. store the configuration in LDAP HBAC rules,
write to files on the client side and then specify them to tlog upon user
login.
However, I'm also rather fond of the idea of specifying the whole
configuration through an environment variable instead of through a file
referenced by an environment variable - it's not big at all, and we'll avoid
the hassle of managing the files.
I implemented support for both in tlog (was easy).
* We'll have to make nss_sss report user's shell as tlog-rec (how?) and
specify the actual shell to tlog-rec via an environment variable, through
pam_sss (with SSS_PAM_ENV_ITEM messages). I.e.:
* Nss_sss would always report tlog-rec as the user's shell.
* During login (e.g. through "login" or "sshd") pam_sss would add a variable
to the user environment, containing, or pointing at, a tlog-rec
configuration (TLOG_REC_CONF_TEXT or TLOG_REC_CONF_FILE). That
configuration would contain the user's actual shell. I can also implement
support for a separate variable just for the shell (TLOG_REC_SHELL?) to
simplify the implementation for the start.
* Tlog-rec would read the system-wide configuration and overlay it with the
one specified in the environment, adding the specific user shell, and then
would spawn it.
Please also see the draft integration design page [3] for reference.
I hope to refine and extend it in the coming weeks to match FreeIPA standards.
Please chime in and suggest, object, discuss!
Also, please report tlog bugs at https://github.com/spbnick/tlog/issues
Thank you!
Nick
[1]: http://www.freeipa.org/page/SELinux_user_mapping
[2]: http://www.freeipa.org/images/b/b9/Freeipa30_SELinuxUserMap.pdf
[3]: http://www.freeipa.org/page/Session_Recording
6 years, 8 months
[PATCH] PAM: Allow to configure pam services for smartcards
by Lukas Slebodnik
ehlo,
attached patch should fix ticket #2926
The default case (no adding, no removing services) is tested
by pam-srv-tests.
If the patch is not ready for stable branch sssd-1-13
then we might merge this case with GPO code which uses slightly
modified way using hash tables.
LS
7 years, 4 months
[PATCH SET} A new Secrets service
by Simo Sorce
This patchset implements a new responder like service in SSSD called
secrets. It uses the Custodia project API to offer a service where
applications/users can store secrets in a way that makes requests
remotizable and routable with a high degree of configurability (esp, in
conjunction with a Custodia proxy).
Included are also accessory patches to change the monitor and other
aspects of service startup and monitoring necessary to have this new
kind of service which is more independent than the pam/nss based
services.
There is no testsuite for the service yet.
The work is also not complete in that the monitor does not start the
service yet, I have an experimental unit file I am working on but it is
not fully functional and not included yet..
I do not expect all patches to be accepted right away, but they all work
individually (manually tested), but I think it is a good time to start
review and bring in what works, as we are going to spread some of the
remaining work across multiple people.
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
7 years, 5 months
[PATCH] sdap: improve filtering of multiple results in GC lookups
by Sumit Bose
Hi,
this patch fixes and issue during initgroups in AD forests. Please see
the commit message for details.
To reproduce this you can create a new user outside of CN=Users on the
forest root. The new user can be created in an existing container or in
a new OU container. Most important is that it is not a child of
CN=Users. In a child domain (it must be a child, domains with a
different base won't trigger the issue) create a user with the same
name. With this setup 'id user(a)forest.root' will not return the complete
list of group the user is a member of and the patch should fix this.
bye,
Sumit
7 years, 5 months