If the user's primary GID was not provided by the SSSD domain, we would
throw an error and fail the access check.
This is not a security vulnerability, as it would never allow an
unauthorized user access, it would only deny access to valid users.
Consumers of the SSSDConfig API like authconfig need an option they can
set to provide a comment. The easiest way to do this would be to provide
a description option that does nothing.
This way, authconfig can notify users that a particular domain is under
authconfig's control and that users should change its name if they don't
want it to be modified by subsequent authconfig runs.
Also related to https://bugzilla.redhat.com/show_bug.cgi?id=697893
Patch 0001: Added a debug message to see which record type we're
processing on each loop through sdap_process_message(). This is purely
Patch 0002: Add support for paged LDAP results.
I changed the internals of sdap_get_generic_send() somewhat here and
added a new sdap_get_generic_internal() routine that can be used to
handle multiple calls to LDAP for a single request. We should be able to
use this in the future to handle Active Directory's non-standard
attribute-level paging as well (though that's not addressed in this
Patch 0003: Add ldap_page_size configuration option
I made this a separate patch for simplicity of review. I set 1000
records as the default, as this seemed to be the most-compatible value
among 389, OpenLDAP and ActiveDirectory as best I could determine.
[PATCH 1/2] Require openssl-devel is libcrypto backend is selected
I've changed the configure flags a little. The previous --enable-crypto
sounded like something you should enable to get the functionality
compiled in rather than a selection of alternative crypto back end.
[PATCH 2/2] BUILD.txt: Warn that all crypto features are implemented
Note that the recommended default is NSS.
On Tue, 2011-04-26 at 04:52 +0530, arun scaria wrote:
> Dear Stephen,
> I'm so thrilled that i got in. Thanks for your faith in me.
We're glad to have you with us. It's going to be an exciting summer!
> So whats the next step? Do I need to take any official procedures. I
> hope we don't want to wait for the official call.
There's no need to wait for the official call, no. If you're ready to
get started, let's not allow bureaucracy to stand in the way. I'm also a
first-time mentor, so I'm learning the process along with you.
> I installed fedora 15 alpha on my machine. I hope i need to hang
> around there to get an idea about how it works.
> Anyway I've some doubts. How should i contact you? Through
> mail or IRC.
It's a good idea to hang out in IRC whenever you're working on SSSD.
There are usually SSSD devs active in there between 0500 and 1800 EST
(we have devs in Germany and the Czech Republic, as well as in the USA).
Ideally, all design discussions should happen on the sssd-devel mailing
list, so they're saved for future reference. We'll also want you to set
up a Fedora Account so you can use the SSSD Trac wiki for your design
I'm CCing the sssd-devel list on this reply, so please continue this
> Is there any need to be highly formal while in SSSD channel?
Not at all. Most of us are highly informal :)
> Is there any documents or related technologies I need to follow in
> order to understand the SSSD source?
The biggest two would be:
This gives a high-level overview of how the SSSD is designed (it's a
little out of date now, but still mostly correct)
will give you a quick primer in talloc, the hierarchical memory
allocator that we use in the SSSD.
which will give you a little bit of a view on how the backends are
implemented (though the example there is more about writing a new
backend for the existing provider types, while you're going to be
writing a new provider type).
> with **WARM** regards,
> Arun Scaria (r00tkit)
> Arun Scaria
> Project Head | MEC Association of Computer Students
> Resource Head | MACS Forum
> Computer Science and Engineering (2008-2012)
> Govt. Model Engineering College
> (M) +918089528527.
I'm sending two patches solving selection of appropriate principal for GSSAPI
authentication from keytab file.
A part of the first patch is a fix of an error present in the documentation. I
did that early in the development phase of the patch and I didn't want to
tamper with the finished patch any more. Sorry for this inconsistency.
These changes are all related to the following ticket:
Changes in SSSDConfig.py merge old and new domain record instead of just
deleting the old and inserting the new one. The old approach let to loss
of some information like comments and blank lines in the config file.
Changes in API config were performed so our Python scripts (like
sss_obfuscate) don't add extra config options to the config file.