[RFC] Keep sysdb context in domain info struct
by Sumit Bose
Hi,
while working on sub-domains I started wondering why we do not keep the
sysdb handle in the sss_domain_info struct? This would make some thing
easier for sub-domains and would safe some cycles for standard domain,
because we do not need the string comparison in
sysdb_get_ctx_from_list().
I did some tests with the attached patch and didn't found any issues. If
you do not have any concerns and think this is a good idea I can provide
a more complete patch.
bye,
Sumit
12 years, 3 months
[PATCHES] Couple enhancements of HBAC code
by Jan Zelený
Hi,
I'm sending two patches with enhancements related to IPA HBAC code. I stumbled
upon these while doing the SELinux work because I'm planning to re-use some
parts of the HBAC code.
#081:
Comment ipa_host_search_base in man pages - nothing special about this one
#082:
Add support for multiple host search bases in HBAC code. I recall we discussed
this one several weeks ago and the conclusion was that we wanted the support
but it wasn't the number one topic at that moment.
The only limitation in my implementation is related to multiple search bases
in combination with dereference code. Basically, if ipa_support_srchost =
false and there is a filter given in host search base, I ignore it. I believe
something similar is already in other parts of SSSD using deref. Correct me if
I'm wrong.
I'd like to ask you for quick review, since my SELinux work depends on this.
Thanks
Jan
12 years, 3 months
Re: [SSSD] [Freeipa-users] New SSSD FAQ page in the works
by Stephen Gallagher
On Wed, 2012-01-11 at 12:56 -0500, Dmitri Pal wrote:
> On 01/10/2012 02:31 PM, Stephen Gallagher wrote:
> > It's come up more than once that SSSD needs a Frequently Asked Questions
> > page to field some of our more common questions. I'm reaching out to the
> > SSSD and FreeIPA user and developer communities to help us flesh out
> > this page.
> >
> > I've begun it with the two most common questions I've received lately,
> > as well as a basic primer on enabling debug logging to help identify
> > issues.
> >
> > I'd like some additional suggestions on what questions should be
> > answered on that page, as well as opening the page to volunteer-edits to
> > add answers to any questions they may have had and solved (or enlisted
> > aid in solving) in the past.
> >
> > The page is available at https://fedorahosted.org/sssd/wiki/FAQ and can
> > be edited by anyone with a free Fedora account. If you don't have one,
> > you can register quickly and easily at
> > https://admin.fedorahosted.org/accounts
> >
> > Thank you very much for your contributions.
> >
> > Once this page has some meat, I will also be looking for interested
> > translators to take a stab at making it accessible to non-English-native
> > users.
> >
> > _______________________________________________
> > Freeipa-users mailing list
> > Freeipa-users(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> 1) What platforms SSSD is supported on?
Added to the FAQ
> 2) Is there an API to configure it?
I think this is more suitable for a separate porting/packaging page,
which we should probably also start writing.
> 3) What are the valid combinations of identity+password+authentication
> +authorization data providers - should be pointer to a page that
> contains a matrix
I agree we should describe this somehow, but I'm not sure what mechanism
to use. A matrix doesn't really work because we have four providers (ID,
AUTH, ACCESS and CHPASS) that need to interact. It's hard to create a
four-dimensional matrix on a two-dimensional surface.
> 4) When should I use enumeration=true ?
Added to the FAQ
12 years, 4 months
SSSD and Kerberos
by Alexander Blair
Hello,
I've been working with FC 16 and SSSD for about two days now trying to
get SSSD to properly talk to our Kerberos server, and it seems to
continually ignore the fact I've got it configured to do so at this
time. Tracking the logs has shown me nothing useful as of yet, and
monitoring network traffic on the Krb server itself shows that there's
no network communication happening.
I've even gone as far as to completely purge the working directory for
it's caches, and force them to rebuild, restarting the box, nothing I've
done so far seems to force SSSD to contact Krb for auth information, any
ideas on where to take this would be most excellent.
I'm currently using SSSD 1.6.3 from the main FC repos. I've gone though
as much troubleshooting information as I can, but as there does not
appear to be any errors in my krb5_child.log log, or much else that
appears to be useful, so I'm a bit stumped.
/etc/sssd/sssd.conf:
[domain/domain]
ldap_id_use_start_tls = False
cache_credentials = True
ldap_search_base = dc=dc,dc=dc,dc=dc
krb5_realm = this.is.a.valid.realm
krb5_server = 192.168.100.100
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_uri = ldap://192.168.100.200/
krb5_kpasswd = 192.168.100.100
ldap_tls_cacertdir = /etc/openldap/cacerts
[sssd]
services = nss, pam
config_file_version = 2
domains = domain
[nss]
[pam]
/var/log/sssd/sssd_nss.log -- Debug level 4:
(Fri Dec 30 01:46:35 2011) [sssd[nss]] [accept_fd_handler] (4): Client
connected!
(Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_getpwnam] (4):
Requesting info for [user] from [<ALL>]
(Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4):
Requesting info for [user@default]
(Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_initgroups] (4):
Requesting info for [user] from [<ALL>]
(Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_initgroups_search] (4):
Requesting info for [user@default]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4):
Requesting info for [user] from [<ALL>]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4):
Requesting info for [user@default]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4):
Requesting info for [user] from [<ALL>]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4):
Requesting info for [user@default]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4):
Requesting info for [user] from [<ALL>]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4):
Requesting info for [user@default]
Thank you,
Alexander Blair
12 years, 4 months
[www.transifex.net] New announcement from SSSD
by Transifex
Hello sssd, this is Transifex at https://www.transifex.net.
A new announcement has been posted from project 'SSSD':
## Planning string freeze for SSSD 1.8.0
SSSD will be releasing a beta of 1.8.0 (called 1.7.91) on February 5, 2012.
At this time, we will be in string freeze until the release of SSSD 1.8.0 on February 28, 2012.
This should offer a reasonable amount of time for translators to submit new strings. We apologize that in the past our string freezes have been short (or nonexistent). We are trying to adjust our scheduling so that in the future there will always be a three-week minimum string freeze for major versions.
-
To view the announcement in Transifex, please visit the following link:
http://www.transifex.net/projects/p/sssd/announcement/1525/
Always at your service.
--
Transifex -- Open Translation Platform
To change your notification settings, please visit your profile page at http://www.transifex.net/notices/.
12 years, 4 months
[PATCH 0/0] A shared memory cache to perform better
by Simo Sorce
Hello team,
the recent break provided me with some spare time and I decided to use
it to make a gift to SSSD.
Santa agreed that SSSD has been a good kid this year and here we go :-)
2 years ago I opened this bug:
https://fedorahosted.org/sssd/ticket/357
[SSSD should provide fast in memory cache to provide similar
functionality as NSCD currently provides]
I have been thinking about this feature since I started the SSSD project
more than (gasp!) 3 years ago, time flies ...
So after a few weekend musings during last fall I had enough will and
clout to actually go and do it in small sprints during my vacation.
The feature is not finalized, many small touches are still necessary but
the bulk of it is there and it happens to work too :-)
Currently only the passwd and group maps are implemented and
enumerations are not cached this way by design.
During the process of creating this feature I also found some minor bugs
or changes that would help it.
So the patchset has been split in 4 batches
0/1: general fixes for bugs I found while coding
These patches should be quite straight forward and would be nice to
apply them asap.
0/2: changes to make life easier for later patches
These change some internals of fill_pwent() and fiull_grent() and can be
applied on their own. I think they also simplify, slightly, reading
those functions, but that's probably a matter of taste.
It would be nice to have these patches pushed (unless there are issues
with them) reasonably soon in order to avoid a lot of churn and rebases
if they stomp on some other people work.
0/3: New utility functions/headers
These are also quite straightforward but they are useless without the
later patches
0/4: Actual memory cache implementation
These is the bulk of the work, these patches are still a bit rough at
the edges, grep for FIXMEs and TODOs and you'll see some plumbing (for
example configure options in sssd to set expiration time and cache sizes
are missing and are still harcoded).
The reason I am sending them is that this is a pet project for me so I
will work on it only off working hours, and that means I have less time
for it now that vacations are over.
But it is really close to be an experimental feature imo, so I would
like a general review from the list to see if there is anything major
that people think should be changed before I take some time the next
weekend (or one of the next sleepless nights :-) to polish the patches
further.
All comments are really welcome, because even if it is a pet project I
would really like to see it committed soon in master as it gives a nice
performance boost in some situations.
Also more can be built on it that is not available now, like negative
caching, a better allocation algorithm for cache blocks, etc...
Have fun and let me know what you think.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12 years, 4 months
[DESIGN]SELinux user roles
by Jan Zelený
Hello everybody,
I'm sending a rough design of SELinux rules and the architecture of how I plan
to implement them. This a plan that I came up with kinda quickly, so it's
rather crude, please consider it only aguidance to show concepts, don't look
for exact attribute names and similar stuff.
What I'm not completely sure about are those potentially very large filter to
handle everything in very small number of queries to remote server - do you
think it's doable this way or should I rather implement client-side filtering?
Assumptions:
===========
1. pam_sss will be configured in session part of PAM stack, thus receiving and
forwarding SSS_PAM_OPEN_SESSION messages
2. We already have a list of all groups the user is member of when
SSS_PAM_OPEN_SESSION message arrives
Chain of actions:
==============
1. pam_sss receives and forwards SSS_PAM_OPEN_SESSION to PAM responder
2. PAM responder issues DP_METHOD_PAM_HANDLER DBUS call with pd->cmd ==
SSS_PAM_OPEN_SESSION
3. IPA provider receives the DBUS method and invokes a callback for new target
BET_SESSION (or BET_SELINUX?)
3. IPA provider checks if it is also configured to be used as access provider
3.1. If not, it queries remote server for host record and related host groups
(I plan to somehow utilize contents of ipa_hbac_hosts.c for that)
4. One query for applicable SERules, something like:
(|
(HBACRule=*)
(&
(|
(user=<login>)
(user=<group1>)
(...)
)
(|
(host=<hostname>)
(host=<hostgroup1>)
(...)
)
)
(default=1)
)
5. IPA provider checks if it is also configured to be used as access provider
5.1. If not, it performs one query for needed HBACRules and stores them in
sysdb
(|
(dn=<HBACRule1>)
(...)
)
6. Filter HBAC rules based on: user/group, host/hostgroup, Allow
7. Filter SERules based on HBAC dns (basically delete those that were
retrieved from the server based on (HBACRule=*) and the target HBAC rule is
not in the filtered list)
8. Store filtered SERules to sysdb
9. Create PAM response of new type SSS_PAM_SEUSER_DATA, send it to responder
10. Re-send the reply to PAM client
11. Decode the response and give the list to pam_selinux - here are following
three options how to do that, but I'm not looking for the best solution right
now:
a) pam_setenv/pam_getenv
b) pam_set_data/pam_get_data
c) directly writing to a particular file in /etc/selinux
Any input is welcomed
Thanks
Jan
12 years, 4 months
[PATCH] old glibc compat
by Simo Sorce
The murmurhash3.c file is using macros from endian.h that are not
available in glibc 2.5 apparently.
The attached patch fixes the build on such machines (like RHEL5).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12 years, 4 months