ssh does not remove credential cache at logout
by Qing Chang
IPA clients (RHEL, CentOS and Unbuntu 12.04) does not clear
credential cache files when a user logout from a ssh session.
pam_sss man page does not have much information on how
it manage to clean out a session when the session is ended.
This is my sshd and session_common file:
===== sshd =====
@include common-auth
account required pam_nologin.so
@include common-account
@include common-session
session optional pam_motd.so # [1]
session optional pam_mail.so standard noenv # [1]
session required pam_limits.so
session required pam_env.so # [1]
session required pam_env.so user_readenv=1 envfile=/etc/default/locale
@include common-password
=====
===== common-session =====
auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_sss.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_cap.so
=====
Is this a pam configuration issue or a pam_sss issue?
Thanks,
Qing
--
------------------
Qing Chang
Senior Systems Administrator
M6-624 Research Computing
Sunnybrook Health Sciences Centre
2075 Bayview Ave.
Toronto, Ontario, M4N 3M5
(416) 480-6100 x3263
qchang(a)sri.utoronto.ca
------------------
10 years, 6 months
[PATCH] IPA server mode: properly initialize ext_groups
by Sumit Bose
Hi,
when writing the code to read IPA memberships for trusted AD users I
didn't carefully check how struct ipa_server_mode_ctx is initialized.
Hence the new member I have added was not properly initialized. This patch
should fix it.
bye,
Sumit
10 years, 6 months
[PATCH v2] Debug macro refactoring
by Nikolai Kondrashov
Hi everyone,
Please find attached my updated patches refactoring the DEBUG macro (mostly).
I've moved the level limiting condition to the macro as requested by Simo.
I've separated the macro definition update from the invocation update.
I've tried using coccinelle ("spatch") to do the invocation update, but
unfortunately, it either puts all DEBUG macro arguments on a single line with
a simple semantic patch (debug.spatch), or puts parts of the concatenated
string literals on a single line with an unrolled version
(debug_unrolled.spatch). I haven't managed to find another way.
So, for this simple case, Perl seems to be better (if not so reliable).
I've used the following command to update the invocations:
grep -rwl --include '*.[hc]' DEBUG . |
while read f; do
mv $f{,.orig}
perl -e 'use strict;
use File::Slurp;
my $text=read_file(\*STDIN);
$text=~s#(\bDEBUG\s*\([^(]+)\((.*?)\)\s*\)\s*;#$1$2);#gs;
print $text;
' < $f.orig > $f
done
And then manually fixed two or three cases where it got confused and has
broken the compilation. After that, coccinelle couldn't find any more places
to update.
You can either use the included patch, try applying one of the semantic
patches, or not convert the macro to variadic and not update the invocations
at all. You can still get the size reduction benefit and fix the flushing.
I will leave this up to you.
If you decide to try the semantic patches, they can be applied as such:
spatch --sp-file debug_unrolled.spatch -dir . | git apply
You will need the "coccinelle" package to get the "spatch" tool.
Sincerely,
Nick
10 years, 6 months
[PATCH v2] Debug macro refactoring
by Nikolai Kondrashov
Hi everyone,
Please find attached my updated patches refactoring the DEBUG macro (mostly).
I've moved the level limiting condition to the macro as requested by Simo.
I've separated the macro definition update from the invocation update.
I've tried using coccinelle ("spatch") to do the invocation update, but
unfortunately, it either puts all DEBUG macro arguments on a single line with
a simple semantic patch (debug.spatch), or puts parts of the concatenated
string literals on a single line with an unrolled version
(debug_unrolled.spatch). I haven't managed to find another way.
So, for this simple case, Perl seems to be better (if not so reliable).
I've used the following command to update the invocations:
grep -rwl --include '*.[hc]' DEBUG . |
while read f; do
mv $f{,.orig}
perl -e 'use strict;
use File::Slurp;
my $text=read_file(\*STDIN);
$text=~s#(\bDEBUG\s*\([^(]+)\((.*?)\)\s*\)\s*;#$1$2);#gs;
print $text;
' < $f.orig > $f
done
And then manually fixed two or three cases where it got confused and has
broken the compilation. After that, coccinelle couldn't find any more places
to update.
You can either use the included patch, try applying one of the semantic
patches, or not convert the macro to variadic and not update the invocations
at all. You can still get the size reduction benefit and fix the flushing.
I will leave this up to you.
If you decide to try the semantic patches, they can be applied as such:
spatch --sp-file debug_unrolled.spatch -dir . | git apply
You will need the "coccinelle" package to get the "spatch" tool.
Sincerely,
Nick
10 years, 6 months
[PATCH] LDAP: Set default value for dyndns update to false
by Lukas Slebodnik
ehlo,
In some cases, local boolean variable "do_update" could be used
without proper initialisation.
Clang static analyser warning: "Assigned value is garbage or undefined"
It was not a big problem, because non-zero value for boolean variable mean
true.
Simple patch is attached.
LS
10 years, 6 months
Fwd: [sudo-users] objectClass=sudoRule vs objectClass=sudoRole in AD
by JR Aquino
This was asked in the SUDO-users mailing list today.
It seemed like something important to cover in here as well.
From: <Curtis.CTR.Roze(a)faa.gov<mailto:Curtis.CTR.Roze@faa.gov>>
Subject: [sudo-users] objectClass=sudoRule vs objectClass=sudoRole in AD
Date: October 11, 2013 5:53:44 AM PDT
To: <sudo-users(a)sudo.ws<mailto:sudo-users@sudo.ws>>
How does the query for sudo rules in AD even work when the debug shows a
query such as:
(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=test.user)(sudoUser=#1215014110)(sudoUser=%test_rmm_linux_users)(sudoUser=%Domain
Users)(sudoUser=%Domain Users)(sudoUser=+*)))
If I execute this on the command line using ldapsearch I get no results.
If I change objectClass to objectClass=sudoRole in the same seach,
ldapsearch works perfectly.
I created the sudoers ou and objects using the guidance in the sudoers
documentation on sudo.ws.
Thanks for the insight.
Curtis Roze
____________________________________________________________
sudo-users mailing list <sudo-users(a)sudo.ws<mailto:sudo-users@sudo.ws>>
For list information, options, or to unsubscribe, visit:
http://www.sudo.ws/mailman/listinfo/sudo-users
10 years, 6 months
[PATCH] Spec file changes for cifs-utils plugin
by Sumit Bose
Hi,
as promised I created the spec file changes to include the cifs-utils
plugin into the sssd-client package on Fedora and RHEL platforms where
recent cifs-utils are available.
bye,
Sumit
10 years, 6 months
Re: [SSSD] [PATCH] CIFS idmap Plugin using SSSD
by Benjamin Franzke
Hi Sumit,
Sorry for the delay, got sidetracked by trying to find an appropriate way
to handle the well known sids etc..
But thanks to your reminder I got over to do the integration into sssd's
autoconf/make now :)
So here is the patch as an attachment.
(as recommended by the contrib page - but if you like it better for review
l'll git send-email it as well..)
This patch does not include an update for the rpm specs.
Could you do that integration? For me as a gentoo user that is currently an
unknown-area :)
Regards, Ben
2013/10/9 Sumit Bose <sbose(a)redhat.com>
> On Mon, Oct 07, 2013 at 12:22:13PM +0200, Benjamin Franzke wrote:
> > 2013/10/7 Sumit Bose <sbose(a)redhat.com>
> >
> > > On Thu, Oct 03, 2013 at 11:57:07PM +0200, Benjamin Franzke wrote:
> > > > >
> > > > > Hi Ben,
> > > > >
> > > > > this is really great, thank you very much for the contribution! As
> a
> > > > > matter of fact, we've been planning on delivering the CIFS plugin
> as
> > > > > part of the next release:
> > > > > https://fedorahosted.org/sssd/ticket/1534
> > > > >
> > > > > Have you found the design page we created?
> > > > >
> > >
> https://fedorahosted.org/sssd/wiki/DesignDocs/IntegrateSSSDWithCIFSClient
> > > >
> > > >
> > > > Yeah, I've read those pages before writing the plugin..
> > > >
> > > >
> > > > >
> > > > > Mostly the work on our side was done by Sumit Bose (I've CC-ed
> him). I
> > > > > would propose to get in touch with him to avoid duplicating some
> > > effort.
> > > > >
> > > > Unfortunately Sumit is in Germany and there is a holiday so he won't
> be
> > > > > available until Monday.
> > > > >
> > > >
> > > > > In general, I would suggest to merge this code into the SSSD tree
> if
> > > you
> > > > > wouldn't mind. I think it would makes sense to have the code in the
> > > same
> > > > > repo as the ID mapping library.
> > > > >
> > > >
> > > > I'd really appreciate having it integrated in sssd tree,
> > > > to have centralized maintainance and adoption by distributions..
> > >
> > > Thanks a lot for the patch. I would suggest to put your code into
> > > src/lib/cifs_idmap_sss/ and modify SSSD's Makefile.am to build the
> > > plugin. Would you like to do the integration and send the result for
> > > review to this list again?
> > >
> >
> > I'd like to do that integration, will send a patch..
>
> I'd like to add the plugin to the next Fedora release which
> unfortunately has its deadline next week. I don't want to rush you, but
> do you have a chance to send the patch today or tomorrow? Otherwise
> would you mind if I prepare the patch to integrate your code into the
> SSSD tree?
>
> Thanks for your help.
>
> bye,
> Sumit
> >
> >
> > > About the well-know SIDs. They should not be handled inside the plugin
> > > but by SSSD itself. If you are interested in adding them I'd be happy
> to
> > > help you how to start (if my help is needed at all :-).
> > >
> >
> > Yup, sounds better to handle the SIDs by SSSD core. I'd like to try..
> > I'll see whether time permits me to do that soon.. (doing this as a part
> of
> > my thesis)
> >
> >
> >
> > >
> > > bye,
> > > Sumit
> > >
> > > >
> > > >
> > > > > Thanks again for the contribution, much appreciated!
> > > > > _______________________________________________
> > > > > sssd-devel mailing list
> > > > > sssd-devel(a)lists.fedorahosted.org
> > > > > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> > > > >
> > >
> > > > _______________________________________________
> > > > sssd-devel mailing list
> > > > sssd-devel(a)lists.fedorahosted.org
> > > > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> > >
> > > _______________________________________________
> > > sssd-devel mailing list
> > > sssd-devel(a)lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> > >
>
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>
>
10 years, 6 months
