[sssd PR#50][opened] [RFC] Use GNULIB's compiler warning code
by fidencio
URL: https://github.com/SSSD/sssd/pull/50
Author: fidencio
Title: #50: [RFC] Use GNULIB's compiler warning code
Action: opened
PR body:
"""
This patch series was sent to the sssd-devel and some discussions
already happened there[0]. I've decided to open the PR because there
are some few patches that can be pushed even if we decide to not use
the "many warnings" patches.
Let's keep track of those patches (and discussions related to them) in
the github, in this way we can avoid them to get lost. :-)
[0]: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahoste...
Best Regards,
Changes:
683f72d (Fabiano Fidêncio, 10 weeks ago)
BUILD: Make use of GNULIB's compiler warning code
As GNULIB has the 'manywarnings' module, which basically turns on every GCC
warning, let's make use of it. We can easily blacklist the warnings we
cannot cope with, but the main goal should be to have enabled every
possible GCC warning.
When new GCC warnings are created the 'manywarnings' file can be refreshed
from upstream GNULIB.
Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com>
f59828a (Fabiano Fidêncio, 5 days ago)
NSS: Fix "old-style-definition" warning caught by GCC
Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com>
f22aff7 (Fabiano Fidêncio, 5 days ago)
SIFP: Fix a "jump-misses-init" warning caught by GCC
Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com>
58609d3 (Fabiano Fidêncio, 5 days ago)
RESOLV: Fix a "-Werror=null-dereference" caught by GCC
Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com>
bd1d7fd (Fabiano Fidêncio, 5 days ago)
RESOLV: Simplify reply_weight_rearrange() a little bit
Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com>
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/50/head:pr50
git checkout pr50
6 years
[sssd PR#32][opened] Requesting a pull to SSSD:master from fidencio:wip/#3138
by fidencio
URL: https://github.com/SSSD/sssd/pull/32
Author: fidencio
Title: #32: Requesting a pull to SSSD:master from fidencio:wip/#3138
Action: opened
PR body:
"""
This patch series is intended to solve #3138 by adding a new service
that updates the confdb. As part of the series this service is used by
secrets service.
I only ran CI locally and the two secrets tests have been failing. /o\
Also, I've noticed some weird behavior, where the sssd-update-confdb
service starts for apparently no reason, when upgrading fedora
packages.
Anyways, these pieces of code really need some detailed review as it
was the first time I've been "seriously" playing with TEvent requests.
So, please, consider it more like an RFC than a well finished and
polished code.
Best Regards,
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/32/head:pr32
git checkout pr32
6 years, 2 months
[RFC] Matching and Mapping Certificates
by Sumit Bose
Hi,
I've started to write a SSSD design page about enhancing the current
mapping of certificates to users and how to select/match a suitable
certificate if multiple certificates are on a Smartcard.
My currently thoughts and idea and be found at
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
and for your convenience below as well.
Comments and suggestions are welcome. Please let me know about concerns,
alternatives and missing use-cases/user-stories.
bye,
Sumit
= Matching and Mapping Certificates =
Related ticket(s):
* http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Map...
=== Problem statement ===
==== Mapping ====
Currently it is required that a certificate used for authentication is either stored in the LDAP user entry or in a matching override. This might not always be applicable and other ways are needed to relate a user with a certificate.
==== Matching ====
Even if SSSD will support multiple certificates on a Smartcard in the context of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict (or relax) the current certificate selection in certain environments.
=== Use cases ===
==== Mapping ====
In some environments it might not be possible or would cause unwanted effort to add certificates to the LDAP entry of the users to allow Smartcard based authentication. Reasons might be:
* Certificates/Smartcards are issued externally
* LDAP schema extension is not possible or not allowed
==== Matching ====
A user might have multiple certificate on a Smartcard which are suitable for authentication. But on some host in the environment only certificates from a specific CA (while all other CAs are trusted as well) or with some special extension should be valid for login.
=== Overview of the solution ===
To match a certificate a language/syntax has to be defined which allows to reference items from the certificate and compare the values with the expected data. To map the certificates to a user the language/syntax should allow to relate certificate items with LDAP attributes so that the value(s) from the certificate item can be used in a LDAP search filter.
=== Implementation details ===
==== Matching ====
The pkinit plugin of MIT Kerberos must find a suitable certificate from a Smartcard as well and has defined the following syntax (see the pkinit_cert_match section of the krb5.conf man page or http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for details). The main components are
* <SUBJECT>regular-expression
* <ISSUER>regular-expression
* <SAN>regular-expression
* <EKU>extended-key-usage-list
* <KU>key-usage-list
and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator ('&&' is the default). If multiple rules are given they are iterated with the order in the config file as long as a rule matches exactly one certificate.
'''Question: MIT Kerberos use case-sensitive matching and POSIX Extended Regular Expression syntax, shall we do the same?'''
While <SUBJECT> and <ISSUER> are (imo) already quite flexible I can see some potential extensions for the other components.
<EKU> and <KU> in MIT Kerberos only accept certain string values related to some allowed values in those field as defined in https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by what is supported on server side of the pkinit plugin of MIT Kerberos. Since we plan to extend pkinit and support local authentication without pkinit as well I would suggest to allow OID strings for those components as well (the comparison is done on the OID level nonetheless).
The <SAN> component in MIT Kerberos only checks the otherName SAN component for the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the szOID_NT_PRINCIPAL_NAME OID as mentioned in https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the default pkinit user case of MIT Kerberos I would suggest to extend this component by allowing to specific an OID with <SAN:O.I.D>
==== Mapping ====
Since different certificates, e.g. issued by different CAs, might have different mapping rule, a matching rule must be added if there are more than 1 mapping rule. A single mapping rule without a matching rule might be used as default/catch-all rule in this case.
If multiple rules matches the derived LDAP filter components can be grouped with the or-operator "|".
A mapping rule can use a similar syntax like the matching rule where the LDAP attribute can be added with a ':', e.g.
* <SUBJECT:ldapAttributeName>
* <SAN:O.I.D.:ldapAttributeName>
Currently I see no usage for <ISSUER>, <KU> and <EKU> in mapping rules because they do not contain any user-specific data. If at some point we will have personal CAs we might consider to add <ISSUER> based mappings.
'''Question, do we need search-and-replace at all (or at this stage)? Most of the interesting values from the SAN should be directly map-able to LDAP attributes. And processing the string representation of <SUBJECT> might be tricky as discussed below. Nevertheless the following might be possible:
* <SUBJECT:ldapAttributeName>/regexp/replacement/
* <SAN:O.I.D.:ldapAttributeName>/regexp/replacement/
'''where "/regexp/replacement/" stands for optional sed-like substitution rules. E.g. a rule like
{{{
<SUBJECT:samAccountName>/^CN=\([^,]*\).*$/\1/
}}}
'''would take the subject string 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and generate a LDAP search filter component '(samAccountName=Certuser)' which can be included in a LDAP search filter which includes additional components like e.g. an objectClass.
'''The search-and-replace does not has to be sed-like because afaik there is not library which offers this and I would like to avoid implementing it. GLib e.g. has [https://developer.gnome.org/glib/stable/glib-Perl-compatible-regular-expr... g_regex_replace]. Since we already have a GLib dependency in SSSD due to soem utf8 helper functions using might be acceptable as well. Nevertheless it would be nice to hear if there are alternative libraries available as well.
'''
===== Some notes about DNs =====
The X.500 family of standards define names as "SEQUENCE OF RelativeDistinguishedName" where the sequence is "starting with the root and ending with the object being named" (see X.501 section 9.2 for details). On the other hand RFC4514 section 2.1 says "Otherwise, the output consists of the string encoding of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first." This means that the ASN.1 encoded issuer and subject DN from the X.509 certificate can be either displayed as string in the
* X.500 order: DC=com,DC=example,CN=users,CN=Certuser
or in the
* LDAP order: CN=Certuser,CN=Users,DC=example,DC=com
As a consequence different tools will use a different order when printing the issuer and subject DN. While NSS's certutil will use the LDAP order, 'openssl x509' and gnutls's certtool will use the X.500 order (the latter might change due to https://gitlab.com/gnutls/gnutls/issues/111).
This makes it important to specific the order which is used by SSSD for mapping and matching. I would prefer the LDAP order here. E.g. by default the AD CA uses the DN of the users entry in AD as subject in the issues certificate. So a matching rule like '<SUBJECT:dn>' could tell SSSD to directly search the user based on its DN (which btw is the original intention of the subject field in the certificate, only that the DN should be looked up in a more general DAP as defined by X.500 and not in the lightweight version called LDAP)
Another issue is the limited set of attribute names/types required by the RFCs (see section 4.1.2.4 of RFC 3280 and section 3 of RFC 4514). If e.g. the deprecated OID [http://www.oid-info.com/get/1.2.840.113549.1.9.1 1.2.840.113549.1.9.1] is used all tools are able to identify it as an email address but OpenSSL displays it as 'emailAddress=user(a)example.com', certtool as 'EMAIL=user(a)example.com' and certutil as 'E=user(a)example.com'. So matching rules should try to avoid attribute names or only the ones from [https://www.ietf.org/rfc/rfc4514.txt RFC 4514]:
* CN commonName (2.5.4.3)
* L localityName (2.5.4.7)
* ST stateOrProvinceName (2.5.4.8)
* O organizationName (2.5.4.10)
* OU organizationalUnitName (2.5.4.11)
* C countryName (2.5.4.6)
* STREET streetAddress (2.5.4.9)
* DC domainComponent (0.9.2342.19200300.100.1.25)
* UID userId (0.9.2342.19200300.100.1.1)
==== About restricting or enforcing the mapping an matching any further ====
The goal of the matching rules in MIT Kerberos is to select a single certificate from a Smartcard which will then be used for PKINIT. Since we already plan to enhance SSSD to support multiple certificates on a Smartcard and if needed prompt the user which one to use for login we should not enforce that the matching rules should return only a single certificate or nothing.
Similar we plan to enhance SSSD to use the same certificate to log in with different user identities, e.g. as a user with standard privileges or as a user with administrator privileges. So it can make sense that multiple mapping rules apply to the same certificate and the related LDAP search filter components are or-ed together.
In many cases the login program will first ask for a user name which will help to restrict the number of suitable certificates even further and the mapping rules are only needed to check if the certificate belongs to the user trying to log in.
But gdm has a feature where gdm will detect when a Smartcard is inserted and call PAM without a user name. In this case SSSD has to determine the user name based on the certificates found on the Smartcard. If in this case multiple valid certificates are on the card and the mapping rules will return multiple users for each certificate gdm has to display a quite long selection of certificate-user pairs the user has to choose from.
So it should be underlined in the documentation that the matching and mapping rules should be detailed and specific so that for the given environment they help to avoid cases where the user is prompted to select a certificate (or user name in the gdm case) when trying to log in.
==== Storing matching and mapping configuration ====
On the IPA server a new objectclass can be created to store an matching-mapping rule pair. Both attributes are optional because a missing mapping rule would mean that the user entry will be search with the whole certificate. A missing matching rule will indicate catch-all rule with a default mapping.
Specifying matching-mapping rules in sssd.conf is a bit more complicated because SSSD does not respect multiple entries with the same keyword, only the last one is used. So all rules have to be added to a single line. To give it a little bit of structure the rules can be enclosed by curly-braces '{}{}' and each rule pair is separated by a comma ','. A single rule in curly braces indicates a matching rule and the mapping will be done with the whole certificate. A default/catch-all mapping rule will start with an empty pair of curly braces followed by a pair containing the mapping rule.
===== Examples =====
* '''certificate_rules = {<EKU>msScLogin}''': only allow certificates with have the Microsoft OID for Smartcard logon 1.3.6.1.4.1.311.20.2.2 set. use the whole certificate to look-up the user. The same result can be achieved with
* '''certificate_rules = {<EKU>1.3.6.1.4.1.311.20.2.2}''': see above
* '''certificate_rules = {<ISSUER>*my-company*<SAN:rfc822Name>*(a)my-company.com$}{<SAN:rfc822Name:mail>}''': only allow certificates form the 'my-company' issuer which have an email address from the 'my-company.com' domain in the rfc882Name SAN attribute. Use the email address in a LDAP search filter '(mail=email-address)' to find the matching user.
=== Configuration changes ===
Does your feature involve changes to configuration, like new options or options changing values? Summarize them here. There's no need to go into too many details, that's what man pages are for.
=== How To Test ===
This section should explain to a person with admin-level of SSSD understanding how this change affects run time behaviour of SSSD and how can an SSSD user test this change. If the feature is internal-only, please list what areas of SSSD are affected so that testers know where to focus.
=== How To Debug ===
Explain how to debug this feature if something goes wrong. This section might include examples of additional commands the user might run (such as keytab or certificate sanity checks) or explain what message to look for.
=== Authors ===
Give credit to authors of the design in this section.
6 years, 5 months
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, 6 months
[sssd PR#66][opened] Minor Dynamic DNS fixes
by fidencio
URL: https://github.com/SSSD/sssd/pull/66
Author: justin-stephenson
Title: #66: Minor Dynamic DNS fixes
Action: opened
PR body:
"""
To provide a bit more information, one of the fixes is to correct NULL being printed here(https://fedorahosted.org/sssd/ticket/3220):
[nsupdate_msg_create_common] (0x0200): Creating update message for realm [(null)].
For the other(https://bugzilla.redhat.com/show_bug.cgi?id=1386748), It is not uncommon for nsupdate to successfully update DNS records but report the error below which results in return(2) to be called inside nsupdate code
TSIG error with server: tsig verify failure
It is easy to reproduce with AD DNS changing Dynamic DNS to 'Nonsecure and secure' on the Zone Properties.
This patch allows PTR records to continue when this happens, however in this case our debug log messages still report failure and I think some improvement should be made here(not sure how exactly though)
[child_sig_handler] (0x1000): Waiting for child [3710].
[nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [512]
[child_sig_handler] (0x0020): child [3710] failed with status [2].
[be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158238]: Dynamic DNS update failed
It would be nice to correct this at the nsupdate level if this is not the expected behavior also.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/66/head:pr66
git checkout pr66
6 years, 7 months
[sssd PR#67][opened] UTIL: Unset O_NONBLOCK for ldap connection
by fidencio
URL: https://github.com/SSSD/sssd/pull/67
Author: lslebodn
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection
Action: opened
PR body:
"""
Before the commit 75e66c388862a4ba05afe0791c5503226395bad0,
the flag O_NONBLOCK was set only for the connect syscall
in request sssd_async_connect_send -> sssd_async_connect_send.
Such change was done for secrets provider.
However, if ldap is compiled with gnutls it caused problems with
start_tls and ldaps.
OpenLDAP Server log:
5810cf2f connection_get(23): got connid=1042
5810cf2f connection_read(23): checking for input on id=1042
TLS: error: accept - force handshake failure: errno 11 - moznss error -12234
TLS: can't accept: TLS error -12234:SSL received an unexpected Application Data record..
5810cf2f connection_read(23): TLS accept failure error=-1 id=1042, closing
5810cf2f connection_close: conn=1042 sd=23
sssd domain log:
[simple_bind_send] (0x0100): Executing simple bind as: uid=user1,dc=example,dc=com
[simple_bind_send] (0x2000): ldap simple bind sent, msgid = 2
[sdap_op_add] (0x2000): New operation 2 timeout 6
[sdap_process_result] (0x2000): Trace: sh[0x151c240], connected[1], ops[0x1515700], ldap[0x1511bd0]
[sdap_process_result] (0x2000): Trace: end of ldap_result list
[sdap_process_result] (0x2000): Trace: sh[0x151c240], connected[1], ops[0x1515700], ldap[0x1511bd0]
[sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server]
[sdap_handle_release] (0x2000): Trace: sh[0x151c240], connected[1], ops[0x1515700], ldap[0x1511bd0], destructor_lock[0], release_memory[0]
[remove_connection_callback] (0x4000): Successfully removed connection callback.
[sdap_op_destructor] (0x1000): Abandoning operation 2
[dp_req_done] (0x0400): DP Request [PAM Authenticate #3]: Request handler finished [0]: Success
[_dp_req_recv] (0x0400): DP Request [PAM Authenticate #3]: Receiving request data.
[dp_req_destructor] (0x0400): DP Request [PAM Authenticate #3]: Request removed.
[dp_req_destructor] (0x0400): Number of active DP request: 0
[dp_method_enabled] (0x0400): Target selinux is not configured
[dp_pam_reply] (0x1000): DP Request [PAM Authenticate #3]: Sending result [4][LDAP]
Resolves:
https://fedorahosted.org/sssd/ticket/3189
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/67/head:pr67
git checkout pr67
6 years, 8 months
Design discussion: Fleet Commander integration
by Jakub Hrozek
Hi,
with Alexander's help, I wrote up a design page about how SSSD should
read Fleet Commander data from IPA and present them to the FC client
component. The SSSD part is described here:
https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration
and the IPA part is here:
https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Featu...
For convenience, I copied the SSSD wiki page below. Comments are welcome!
= Feature Name =
Related ticket(s):
* https://fedorahosted.org/sssd/ticket/2995
=== Problem statement ===
FleetCommander is a service to centrally manage Desktop environments. It includes a server to define desktop profiles and a client to apply profile information to the user's desktop session on a specified machine.
This design document describes the SSSD part of
an integration of FleetCommander with FreeIPA. The
integration is done two-fold, the IPA part of the integration is
[https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Featu... documented separately].
=== Use cases ===
As an administrator, I want to manage desktop profiles in a centralized way
As an administrator, I want to use centrally defined users, groups, hosts and host groups to specify how desktop profiles should be applied.
As an administrator, I want to make sure desktop profiles associated with a specific user or user group are downloaded and applied on a specific FreeIPA client according to the desktop profile rules defined in FreeIPA.
=== Overview of the solution ===
FleetCommander consists on two components:
* a web service integrated with Cockpit that serves the dynamic application and the profile data to the network.
* and a client side daemon that runs on every host of the network.
Since this design page deals with the client side of the whole picture, this paragraph will focus on the integration of the FC client side daemon with SSSD.
The FC profiles will be downloaded by a new `session_provider` of IPA. This
provider will do nothing by default and will include an option to download
FC rules from IPA LDAP (perhaps `ipa_enable_fleetcmd = true`).
In order to minimize the required client-side configuration changes, enabling
the Fleet Commander client side deamon will drop SSSD configuration that
enables the SSSD functionality and restarts SSSD.
When a FreeIPA domain user logs in, the IPA provider will download the Fleet
Commander profile and rule objects and drop the resulting JSON files into
a per-user directory. The file names must be normalized and prepended with
priority (please refer to the IPA design page for more details).
In the future, we would like to link the Fleet Commander profiles with
HBAC rules, but the first implementation will not include this part.
=== Implementation details ===
The implementation has two distinct parts -- enabling the IPA session
provider's Fleet Commander functionality and actually fetching the Fleet
Commander data.
==== Enabling the IPA session provider ====
Since searching for the Fleet Commander profiles does not come for free -
at least one LDAP search must be issued, perhaps more unless we cache the
host groups, we should only enable this functionality if the Fleet Commander
client daemon is enabled as well. To this end, enabling the FC client deamon
would trigger a one-shot systemd service that would drop an include file
to SSSD's `conf.d` directory.
The systemd service might be implemented along these lines:
{{{
[Unit]
ConditionFileNotEmpty=/etc/sssd/sssd.conf
ConditionFileNotEmpty=!/etc/sssd/conf.d/fleetcommander.conf
[Service]
Type=oneshot
ExecStartPre=/bin/cp -y /usr/share/fleetcommander/sssd.snippet.conf /etc/sssd/conf.d/fleetcommander.conf
ExecStart=/bin/systemctl try-restart sssd
}}}
This systemd unit might be stored
in `/lib/systemd/system/fleetagent.service.d/sssd.conf`. A similar
functionality in this file should remove the included config file when
the FC client deamon is disabled.
==== Looking up the Fleet Commander profiles and storing the JSON profile data ====
Since the first implementation will only fetch rules that are linked to
this host and the user in question, the SSSD's session provider will issue
an LDAP search along these lines:
{{{
(&(objectclass=ipadeskprofilerule)(memberHost=my_fqdn_or_my_host_group)(memberUser=user_login_or_group))
}}}
All host groups the IPA client is a member of must be included in the
`memberHost` part of the filter. Additionally, all user groups must be
included in the `memberUser` part of the filter. Since in most cases,
the user's groups will be resolved during the login, we will only issue
an initgroups request in case the user's initgroups are expired already
to cover cases where the sessions provider was invoked separately.
The host groups are typically also resolved by the IPA access control
provider, but currently not cached. In the initial implementation, we can
just search the host groups again, but subsequent patches should optimize
the searches by storing the host groups in the cache or in an intermediate
in-memory result.
The LDAP search will include the Fleet Commander payload data in the
profile's `data` attribute. Once the data are known, SSSD will write them
to the disk. Since writing to the disk is typically quite fast
The JSON files will be stored in a new directory owned by the `sssd-ipa`
subpackage. The top-level directory could be at `/var/lib/sss/fleetcmd/`
with per-user subdirectories. So each per-user JSON file would be stored at
`/var/lib/sss/fleetcmd/<username>/<profilename>.json`. The `<username>`
directories need to be owned by the user being logged in.
The `<profilename.json>` file must include the priority as a number which
is read from the rule's `prio` attribute. The Fleet Commander client deamon
will then process the JSON files in this priority. The filenames must also
be normalized so that characters with a special meaning in shell are escaped
and spaces are converted to another character such as underscores. Please
refer to the IPA design page for more details.
In the first version, the profiles will always be written again. In the
future, we might want to optimize the process further by only writing the
JSON profiles if they differ from what's already stored on the disk. This
might be doable by storing the modifyTimestamp in the JSON profiles again,
if FC is able to ignore certain JSON key-value pairs that would be private
to SSSD or just storing the largest USN value of the found profiles in
the included directory in a specially-named file.
=== Configuration changes ===
Two new configuration options will be added:
* `session_provider` that will be inherited from the `id_provider` value, so for IPA clients, this provider will default to `ipa`. A default `session_provider` for other providers will just shortcut and return success.
* An option that enables the FC rules and profiles processing. A proposed option name is `ipa_enable_fleetcmd` with boolean semantics.
=== How To Test ===
Please see the use-cases above.
=== How To Debug ===
DEBUG messages will be added to the new session provider so that the admin
can trace if the session provider was invoked at all. An easy way to debug
the integration is to enable the sessions provider and the FleetCommander
integration manually w/o dropping the file by the FC client side daemon.
=== Authors ===
* Alexander Bokovoy
* Jakub Hrozek
6 years, 9 months
[RFC] NSS tlog integration
by Nikolai Kondrashov
Hi everyone,
Please find attached proof-of-concept patches for a part of NSS integration
with tlog. Namely, addition of shell substitution for getpwnam requests.
The code is supposed to replace a user's shell with /usr/bin/tlog-rec, if
session recording is enabled for all users, if it is enabled for that
particular user, or for a group that it belongs to.
The configuration is done in a dedicated section of sssd.conf named
"session_recording", which can contain three options "scope", "users", and
"groups". Those correspond to the scope of session recording: "none", "some",
and "all", corresponding in order to: disabled session recording, session
recording enabled for the specified users/groups, and session recording
enabled for all users handled by SSSD.
An example of a configuration can be:
[session_recording]
; Disabled
scope = none
or
[session_recording]
; Enabled for everyone
scope = all
or
[session_recording]
; Enabled for some users and groups
scope = some
users = user1, user2
groups = group1, group2
The parts to be done still are adding support for getpwuid and getpwent
requests, exporting of the original shell in pam_sss, and of course cleaning
it up and doing it according to your comments and requirements.
The code has some documentation in doxygen format, which I can change later if
we decide on some other format, or no documentation at all.
Please, tell me if I'm doing anything wrong this far already, or suggest
better ways to do it.
Thank you!
Nick
P.S. I'm on PTO for two weeks starting next week, so might not be able to
answer quickly.
6 years, 9 months
[PATCH] Unit tests for pam_sss using pam_wrapper (need help with CI..)
by Jakub Hrozek
Hi,
the attached patches implement unit tests for the pam_sss module using
pam_wrapper and libpamtest. In my testing, the coverage is around 75%
with mostly the parts that require running as root being untested.
I worked on this patchset even though the features for 1.14 are in full
swing because there are several tickets that will require us to patch
pam_sss, so it's important to have the code that changes tested. In
addition, when we merge Dan's patches to use TLS with integration tests,
then we'll be able to also test authentication in integration tests
easily using libpamtest-python.
However, our CI fails for me constantly:
http://sssd-ci.duckdns.org/logs/job/42/75/fedora_rawhide/ci.html
The strange thing is that running CI locally works fine and so does make
check. Can anyone help point me in the right direction as to what should
I check next? I suspect some of the environment variables might not be
set correctly, but I don't see why..
6 years, 9 months
