MONITOR: Add disable_netlink sssd.conf option
by Justin Stephenson
Hello,
The attached patches resolve https://fedorahosted.org/sssd/ticket/3142
However, I am having difficult with the man page addition to
'src/man/sssd.conf.5.xml' for this new option. I have stared at the open
and close xml tags(for far too long) and it looks correct but when I
build sssd I never see the sssd.conf man page inclusion. Could anyone
tell me what I am missing here?
If you feel there is better wording for the description please let me know.
Kind regards,
Justin Stephenson
6 years, 8 months
Getting overridden shell in pam_sss
by Nikolai Kondrashov
Hi Sumit,
Now I'm again approaching the implementation of tlog integration in pam_sss,
and as planned, I need to get the actual user shell to put it into
TLOG_REC_SHELL environment variable upon opening of the session.
However, the get_shell_override, which does all the hops and tricks to get it,
requires nss_ctx, which belongs to NSS responder, specifically various
shell-related configuration settings
(override_shell/allowed_shells/vetoed_shells/etc_shells). I.e. essentially the
PAM responder needs to be an NSS responder to get it.
To me it seems that there is no exit but to finally put that override
machinery into a library, instead of having it directly in the NSS responder.
Am I wrong? Is there perhaps another way?
Do you have any suggestion how to best do it?
Thanks a lot!
Nick
6 years, 8 months
[RFC] Cleaning up the IFP responder (mainly) and socket-activatable responders
by Fabiano Fidêncio
Howdy!
Taking a look on https://fedorahosted.org/sssd/ticket/2395 seems that
there are a few ways to achieve what's proposed by Simo and I'd like
to discuss one of those before start implementing it.
As far as I understand the bug, SSSD cannot be run as a non-root user
because of IFP responder, which needs to be run as root in order to
write to sssd.conf file. Simo's suggestion was to create a new
service, which should be socket-activated, to handle this writing to
sssd.conf part and Jakub's suggested to completely get rid of this
part. However, Dmitri pointed out that we must have some service
playing with sssd.conf as it's the way that cockpit and ansible can
remotely manage the SSSD configuration.
Okay, in order to actually start solving the issue I'd like to propose
the follow steps:
1) Create a new service, still explicitly enabled in sssd.conf, that
would take care of the managing the SSSD configuration.
2) Get rid of the code dealing with the SSSD configuration from the
IFP responder.
3) Get rid of the OpenLMI specific code from the IFP responder
Till this point the problem wasn't solved at all, but those seem to be
the logical steps in order to make our own lives easier for working in
the next two steps.
4) Make the new service (created in 1) socket-activated/bus-activated.
5) Make the IFP responder also bus-activated/socket-activated.
So, does it sound like a reasonable way to approach the problem?
If yes, I'd like to ask a few questions, mainly about items 4 and 5,
as it eems that in order to achieve what we want,
https://fedorahosted.org/sssd/ticket/2243 and
https://fedorahosted.org/sssd/ticket/3129 have to be solved together,
which seems to be a not so small task.
So, do we have to care about systems that don't have systemd support?
IOW, do we have to keep the current code and also add
socket-activation? If yes, would it be explicitly enabled/disabled on
configure time? Maybe a lame question, but what are the advantages of
the socket-activation over the bus-activation approach (I still didn't
look at any of those :-\)?
Thanks in advance,
--
Fabiano Fidêncio
6 years, 9 months
[sssd PR#8] MAN: Document the ldap_user_gid_number option (opened)
by fidencio
jhrozek's pull request #8: "MAN: Document the ldap_user_gid_number option" was opened
PR body:
"""
Some users, mostly those who cannot join the Linux machines to their AD domain resort to using the LDAP provider with ID mapping.
But in order for that to work correctly, the ldap_user_gid_number option must be set correctly, otherwise SSSD complains about not finding the primary GID:
(Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x0020): Cannot get the GID for [someuser] in domain [extdev].
"""
See the full pull-request at https://github.com/SSSD/sssd/pull/8
... or pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/8/head:pr8
git checkout pr8
6 years, 9 months
[PATCH] GPO: Cat vals with same key from different GPOs
by Michal Židek
Hi,
here is patch for ticket #3161.
See more in the ticket description.
I was thinking why we originally replaced
the lists and I think it comes from confusion
on how we handle the same keys in single
GPO ini file, however that is handled by
libini not by SSSD.
Michal
6 years, 9 months
[sssd PR#7] Fix initgroups with nested groups (comment)
by fidencio
lslebodn commented on a pull request
"""
On (31/08/16 01:47), sumit-bose wrote:
>On Wed, Aug 31, 2016 at 01:30:12AM -0700, Jakub Hrozek wrote:
>> On Wed, Aug 31, 2016 at 12:36:37AM -0700, sumit-bose wrote:
>> > On Tue, Aug 30, 2016 at 12:36:20PM -0700, Jakub Hrozek wrote:
>> > > On Tue, Aug 30, 2016 at 11:47:09AM -0700, lslebodn wrote:
>> > >
>> > > About the discussion I saw on #sssd in backscroll, the rfc2307bis schema
>> > > only uses the member attribute because IIRC the RFC doesn't talk about
>> > > memberof at all. But in IPA, we know the specifics on the schema, so we
>> > > are able to dereference the memberof attribute to get a complete list of
>> > > all groups with one call.
>> >
>> > Unfortunately it is more complicated with IPA because memberOf only
>> > contains the direct memberships, there is a second attribute
>> > memberofindirect which hold the indirect memberships.
>>
>> This is only how IPA UI displays indirect memberships, if you check the
>> memberships with ldapsearch, you'll see it's really only memberof.
>
>bummer, you are right, I thought the --raw option of ipa user-show really
>means 'raw' but it looks some of the values are still processed.
>
>Sorry for the noise.
>
I haven't found any regression caused by this patch.
So at least; issues in ipa-trust test are not caused by this bug.
LS
"""
See the full comment at https://github.com/SSSD/sssd/pull/7#issuecomment-243777706
6 years, 9 months