[PATCH] Add host access control support
by Jan Zelený
I'm sending rebased patch by Pierre Ossman. The patch is adding an option to
allow/deny user access based on host attribute supported by pam_ldap.
I tested the patch and it works just fine. I also have no objections to the
design.
https://fedorahosted.org/sssd/ticket/746
--
Thank you
Jan Zeleny
Red Hat Software Engineer
Brno, Czech Republic
13 years, 1 month
[PATCH] Return from functions in LDAP provider after marking request as failed
by Jakub Hrozek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Attached is a patch that fixes a couple of cases in sdap_async_accounts
where we marke the tevent request as failed but do proceed with the
function. This can lead to crashes - I verified that the hunk in
sdap_group_internal_nesting_done() does, at least.
The last hunk in rfc2307bis_nested_groups_process() may not be necessary
but I think that it makes the code read better.
Jakub
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2LdB8ACgkQHsardTLnvCWWrQCgn0Po//4APM1hOh/jvDJWDesd
XxsAoOSmb8W6QaqGqzWPlhgk2Qjk/DJJ
=rZdV
-----END PGP SIGNATURE-----
13 years, 1 month
Another newbie request for help
by Vic Watson
Hi All.
Sorry for the neophyte nature of my questions, but I'm struggling to get my system running against a tight deadline...
I've got all my machines authenticating logins etc. nicely against sssd. My /etc/pam.d/system-auth works fine.
Now I need to get samba working. My security setting is "user", which I expected to authenticate via pam. My /etc/pam.d/samba just includes system-auth, so that's clearly incorrect, as it completely fails to authenticate.
Does anyone have a potted smb.conf / pam.d/* I could use?
Thanks!
Vic.
13 years, 1 month
[PATCHES] Fix several bugs introduced by the multi-valued name patches
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
These were all discovered by Coverity. The fixes are pretty simple.
Patch 0001: If there's no orig_dn available, we need to fail here since
we can't determine the correct name. This occurs after we've already
processed the case where the name is single-valued.
Patch 0002: Only free *_name if _name is non-NULL.
Patch 0003: Check the correct result of talloc_strdup()
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2KBWIACgkQeiVVYja6o6OV4QCeKVr9LcDa/SISQlBmub8M7T2n
InwAoJkDVmi6uiYLxrBjJBkOGnkJjLPW
=IuCW
-----END PGP SIGNATURE-----
13 years, 1 month
[PATCHES] Various ding-lib fixes
by Sumit Bose
Hi,
this series of patches fixes some issues in ding-libs. Patch 0003 should
fix Coverity issues 10035-10040 and 0004 and 0005 the remaining open
issues.
bye,
Sumit
13 years, 1 month
[PATCH] Eliminate memory leak on error
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fixes Coverity bug 10009
Pushed to ding_libs-0-1 under the one-liner (loosely) rule.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2J7zQACgkQeiVVYja6o6MqawCbBtu49JtXmrVqQ96gv2JyiOWD
XuQAn3/BA7VgcWHgK9UZSixsXXHHHN6T
=4SLG
-----END PGP SIGNATURE-----
13 years, 1 month
[PATCH] Fix incorrect allocation check
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The NULL check after a strdup() was incorrect, causing a false failure
condition as well as a memory leak.
Pushed to ding_libs-0-1 under the one-liner rule.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2J5oYACgkQeiVVYja6o6O7MwCfQArGVb3oWqKOweMU1IrpreOK
DBIAnAiGPEysmR1FN3ZAJ5WvNAJB1QuO
=I45B
-----END PGP SIGNATURE-----
13 years, 1 month
[PATCHES] Handle multi-value names for users and groups
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fixes https://fedorahosted.org/sssd/ticket/818
Patch 0001: Create sysdb_get_rdn() function
This function takes a DN formatted string and returns the RDN
value from it.
Patch 0002: Add sysdb_attrs_primary_name()
This function will check a sysdb_attrs struct for the primary name
of the entity it represents. If there are multiple entries, it
will pick the one that matches the RDN. If none match, it will
throw an error.
Patch 0003: Handle multi-valued usernames correctly
Users in ldap with multiple values for their username attribute
will now be compared against the RDN of the entry to determine the
"primary" username. We will save all of the alternate names to the
ldb cache as well, so a lookup for any of them will return the
values for the primary name.
e.g.
getent passwd altusername
primaryuser:*:800014:800014:primaryuser:/home/primaryuser:/bin/sh
Patch 0004: RFC2307: Handle multi-valued group names correctly
Groups in ldap with multiple values for their groupname attribute
will now be compared against the RDN of the entry to determine the
"primary" group name. We will save all of the alternate names to the
ldb cache as well, so a lookup for any of them will return the
values for the primary name.
e.g.
getent group altgroup
primarygroup:*:800014:member1,member2
Patch 0005: RFC2307bis: Handle multi-valued group names correctly
Groups in ldap with multiple values for their groupname attribute
will now be compared against the RDN of the entry to determine the
"primary" group name. We will save all of the alternate names to the
ldb cache as well, so a lookup for any of them will return the
values for the primary name.
e.g.
getent group altgroup
primarygroup:*:800014:member1,member2
I tested with RFC2307, RFC2307bis and FreeIPA v2 data.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2A8zQACgkQeiVVYja6o6NhlgCfctmTZdWDmsobpeV05vl1YBVd
MEUAn2+lKF0WKRSTWS2xvX1t+6FsCWQ5
=Y2s1
-----END PGP SIGNATURE-----
13 years, 1 month
[PATCH] Use fake groups during IPA initgroups
by Jakub Hrozek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fixes:
https://fedorahosted.org/sssd/ticket/822
[PATCH 1/2] Add originalDN to fake groups
Since we are storing expired groups during initgroups now and some of
the group processing routines depend on originalDN, I think the
originalDN should be stored with the fake groups.
This would help for instance sdap_nested_group_process_step() which
would find the expired group in sysdb and refresh it immediately instead
of trying blind lookup for users and then groups.
[PATCH 2/2] Use fake groups during IPA schema initgroups
Do not just store non-expired groups from LDAP during initgroups and
risks that some of the members might not be there. Instead, add fake
groups for those that are not yet cached and build correct
member/memberof relationship.
There's one more optimization I'd like to make, although I'm not sure if
it is 1.5 material. Since we do not fetch the memberof attribute for
LDAP groups, we must look at all groups when searching for direct
parents for a group (see sdap_initgr_nested_get_direct_parents()).
Having the memberof attribute would allow for an optimization where we
would first filter all parents and then just the direct ones. That would
be very similar to what we can do for the user since we search the
groups based on users' memberof anyway.
Jakub
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2I3jAACgkQHsardTLnvCX8hgCfVx56mnPQmPwMzc6QgfHp8H4R
B/UAniN3Ki/BpTyZu3rg3pBD537xrsoC
=jVyP
-----END PGP SIGNATURE-----
13 years, 1 month
