[PATCH] BUILD: Add contributed macros and aliases to simplify building
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've been meaning to put these together and submit them for a while.
This is the set of macros and aliases I've been using for years to
build SSSD. I played around with them today, adding some
auto-detection for the platform being built, so it should be pretty
robust. I've only tested it on Fedora 18 x86_64 though.
Basically, one should only need to do:
. /path/to/sssd-source/contrib/fedora/bashrc_sssd
cd /path/to/sssd-source
reconfig && chmake
(optionally) sssinstall
And have a working install of the latest sources on the current
machine. The 'remake' and 'warn' aliases come in handy as well. Last
of all it includes a 'genpatch' alias that makes creating patches that
meet our submission guidelines easy.
p.s. These are submitted to the sssd/contrib/fedora directory because
I do not expect them to work on a non-Fedora system (though it may
work on RHEL 6 and later).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlE2RKUACgkQeiVVYja6o6M2wACcCEhk7alWMlk6QQG8WaXdLNVM
5icAnAm+tLAKyB35N5hLP6oyq5kaQkeY
=ad5f
-----END PGP SIGNATURE-----
11 years
Design Discussion: Integrate SSSD with CIFS Client
by Sumit Bose
Hi,
please have a look at
https://fedorahosted.org/sssd/wiki/DesignDocs/IntegrateSSSDWithCIFSClient
This is my understanding about what needs to be done to replace winbind
with sssd with respect to a CIFS client, i.e. cifs kernel module and
cifs-utils packages.
For your convenience the content is added below as well.
Comments and suggestions are welcome.
bye,
Sumit
== Integrate SSSD with CIFS Client ==
Related tickets:
* [https://fedorahosted.org/sssd/ticket/1534 RFE Integrate SSSD with CIFS client]
Designs and tickets this design (might) depend:
* [https://fedorahosted.org/sssd/wiki/DesignDocs/NSSResponderIDMappingCalls ID Mapping calls for the NSS responder]
* [https://fedorahosted.org/sssd/wiki/DesignDocs/GlobalCatalogLookups Global Catalog Lookups in SSSD]
* [https://fedorahosted.org/sssd/ticket/1559 RFE Use the getpwnam()/getgrnam() interface as a gateway to resolve SID to Names]
=== Problem Statement ===
Although mapping of Posix UIDs and SIDs is not needed mounting a CIFS share it might become necessary when working if files on the share, e.g. when modifying ACLs. Up to version 5.8 the cifs-utils package uses Winbind for this exclusively and the following binaries where linked against libwbclient:
* /usr/bin/getcifsacl
* /usr/bin/setcifsacl
* /usr/sbin/cifs.idmap
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton (Thank you very much Jeff) to allow services other than winbind to handle the mapping of Posix UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access CIFS share with the same functionality as a client running Winbind.
=== Overview of the solution ===
=== Implementation details ===
The plugin interface is defined in cifsidmap.h which can be found in the cifs-utils-devel package. For easier reference a copy of the relevant section is included below.
* Form the 6 expected function cifs_idmap_init_plugin() and cifs_idmap_exit_plugin() are obvious.
* cifs_idmap_sid_to_str() and cifs_idmap_str_to_sid() are SID-to-Name and Name-to-SID mappings as discussed in NSSResponderIDMappingCalls. I think the new libsss_nss_idmap.so mentioned there can be used here, too.
* cifs_idmap_sids_to_ids() and cifs_idmap_ids_to_sids() are the ID mapping calls. Although it might be possible possible to map ID algorithmic without talking to SSSD I think those calls should also reach out to SSSD to do the mapping. The main reason is to allow other kind of mappings (e.g. using Posix attributes if available in AD).
{{{
57 /*
58 * Plugins should implement the following functions:
59 */
60
61 /**
62 * cifs_idmap_init_plugin - Initialize the plugin interface
63 * @handle - return pointer for an opaque handle
64 * @errmsg - pointer to error message pointer
65 *
66 * This function should do whatever is required to establish a context
67 * for later ID mapping operations. The "handle" is an opaque context
68 * cookie that will be passed in on subsequent ID mapping operations.
69 * The errmsg is used to pass back an error string both during the init
70 * and in subsequent idmapping functions. On any error, the plugin
71 * should point *errmsg at a string describing that error. Returns 0
72 * on success and non-zero on error.
73 *
74 * int cifs_idmap_init_plugin(void **handle, const char **errmsg);
75 */
76
77 /**
78 * cifs_idmap_exit_plugin - Destroy an idmapping context
79 * @handle - context handle that should be destroyed
80 *
81 * When programs are finished with the idmapping plugin, they'll call
82 * this function to destroy any context that was created during the
83 * init_plugin. The handle passed back in was the one given by the init
84 * routine.
85 *
86 * void cifs_idmap_exit_plugin(void *handle);
87 */
88
89 /**
90 * cifs_idmap_sid_to_str - convert cifs_sid to a string
91 * @handle - context handle
92 * @sid - pointer to a cifs_sid
93 * @name - return pointer for the name
94 *
95 * This function should convert the given cifs_sid to a string
96 * representation or mapped name in a heap-allocated buffer. The caller
97 * of this function is expected to free "name" on success. Returns 0 on
98 * success and non-zero on error. On error, the errmsg pointer passed
99 * in to the init_plugin function should point to an error string. The
100 * caller will not free the error string.
101 *
102 * int cifs_idmap_sid_to_str(void *handle, const struct cifs_sid *sid,
103 * char **name);
104 */
105
106 /**
107 * cifs_idmap_str_to_sid - convert string to struct cifs_sid
108 * @handle - context handle
109 * @name - pointer to name string to be converted
110 * @sid - pointer to struct cifs_sid where result should go
111 *
112 * This function converts a name string or string representation of
113 * a SID to a struct cifs_sid. The cifs_sid should already be
114 * allocated. Returns 0 on success and non-zero on error. On error, the
115 * plugin should reset the errmsg pointer passed to the init_plugin
116 * function to an error string. The caller will not free the error string.
117 *
118 * int cifs_idmap_str_to_sid(void *handle, const char *name,
119 * struct cifs_sid *sid);
120 */
121
122 /**
123 * cifs_idmap_sids_to_ids - convert struct cifs_sids to struct cifs_uxids
124 * @handle - context handle
125 * @sid - pointer to array of struct cifs_sids to be converted
126 * @num - number of sids to be converted
127 * @cuxid - pointer to preallocated array of struct cifs_uxids for return
128 *
129 * This function should map an array of struct cifs_sids to an array of
130 * struct cifs_uxids.
131 *
132 * Returns 0 if at least one conversion was successful and non-zero on error.
133 * Any that were not successfully converted will have a cuxid->type of
134 * CIFS_UXID_TYPE_UNKNOWN.
135 *
136 * On any error, the plugin should reset the errmsg pointer passed to the
137 * init_plugin function to an error string. The caller will not free the error
138 * string.
139 *
140 * int cifs_idmap_sids_to_ids(void *handle, const struct cifs_sid *sid,
141 * const size_t num, struct cifs_uxid *cuxid);
142 */
143
144 /**
145 * cifs_idmap_ids_to_sids - convert uid to struct cifs_sid
146 * @handle - context handle
147 * @cuxid - pointer to array of struct cifs_uxid to be converted to SIDs
148 * @num - number of cifs_uxids to be converted to SIDs
149 * @sid - pointer to preallocated array of struct cifs_sid where results
150 * should be stored
151 *
152 * This function should map an array of cifs_uxids an array of struct cifs_sids.
153 * Returns 0 if at least one conversion was successful and non-zero on error.
154 * Any sids that were not successfully converted should have their revision
155 * number set to 0.
156 *
157 * On any error, the plugin should reset the errmsg pointer passed to the
158 * init_plugin function to an error string. The caller will not free the error
159 * string.
160 *
161 * int cifs_idmap_ids_to_sids(void *handle, const struct cifs_uxid *cuxid,
162 * const size_t num, struct cifs_sid *sid);
163 */
}}}
SSSD will provide a plugin which will basically a wrapper for the calls in libsss_nss_idmap.so.
=== How to test ===
==== Testing with getcifsacl ====
If there is no plugin for the CIFS client utilities or the plugin cannot resolve the SIDs to names getcifsacl will only show the SID strings in the outout:
{{{
# getcifsacl /tmp/bla/Users/Administrator/Desktop/putty.exe
REVISION:0x1
CONTROL:0x8004
OWNER:S-1-5-32-544
GROUP:S-1-5-21-3090815309-2627318493-3395719201-513
ACL:S-1-5-18:ALLOWED/0x0/FULL
ACL:S-1-5-32-544:ALLOWED/0x0/FULL
ACL:S-1-5-21-3090815309-2627318493-3395719201-500:ALLOWED/0x0/FULL
}}}
otherwise the output might look like
{{{
# getcifsacl /tmp/bla/Users/Administrator/Desktop/putty.exe
REVISION:0x1
CONTROL:0x8004
OWNER:BUILTIN\Administrators
GROUP:AD18\Domain Users
ACL:S-1-5-18:ALLOWED/0x0/FULL
ACL:BUILTIN\Administrators:ALLOWED/0x0/FULL
ACL:AD18\Administrator:ALLOWED/0x0/FULL
}}}
==== Testing with cifsacl option to mount.cifs ====
If the cifsacl mount option is used the cifs kernel module will call cifs.idmap to translate the Windows SIDs into the corresponding UIDs/GIDs of the client system so that the ownership of the files in the mounted file system is not mapped to the user how mounted the file system, but corresponds to the owning user and group of the Windows domain.
=== Author(s) ===
Sumit Bose <sbose(a)redhat.com>
11 years
[PATCH] Fixed typo in debug message.
by Lukas Slebodnik
Hello,
I am trying to get familiar with source code of sssd and I found
typo in source code. This is not critical issue, because this is
only debug message. There was more than 2 years :-)
LS
11 years
Invalid assignment to enum
by Lukas Slebodnik
Hi,
I played with clang and there were 2 interesting warnings:
-------------------
../sssd/src/responder/sudo/sudosrv_get_sudorules.c:373:71: warning: implicit conversion from enumeration type 'enum sss_sudo_type' to different enumeration type 'enum sss_dp_sudo_type' [-Wconversion]
cmd_ctx->domain, cmd_ctx->type,
~~~~~~~~~^~~~
../sssd/src/responder/sudo/sudosrv_get_sudorules.c:580:71: warning: implicit conversion from enumeration type 'enum sss_sudo_type' to different enumeration type 'enum sss_dp_sudo_type' [-Wconversion]
cmd_ctx->domain, cmd_ctx->type,
-------------------
Function sudosrv_get_sudorules_query_cache() expects "enum sss_dp_sudo_type"
and type of cmd_ctx->type is "enum sss_sudo_type".
It is a purpose or mistake?
btw: gcc do not throw this warning with flag -Wconversion
LS
11 years
Design Discussion: SSSD should support DNS sites
by Sumit Bose
Hi,
I have created a design page for
https://fedorahosted.org/sssd/ticket/1032 "[RFE] sssd should support DNS
sites" at
https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSSites .
It can be found below as well.
Corrections, comments and enhancements are welcome.
bye,
Sumit
== Use Active Directory's DNS sites ==
Related ticket(s):
* [https://fedorahosted.org/sssd/ticket/1032 RFE sssd should support DNS sites]
=== Problem Statement ===
In larger Active Directory environments there is typically more than one domain controller. Some of them are used for redundancy, others to build different administrative domains. But in environments with multiple physical locations each location often has at least one local domain controller to reduce latency and network load between the locations.
Now clients have to find the local or nearest domain controller. For this the concept of sites was introduce where each physical location can be seen as an individual site with a unique name. The naming scheme for DNS service records was extended (see e.g. http://technet.microsoft.com/en-us/library/cc759550(v=ws.10).aspx) so that clients can first try to find the needed service in the local site and can fall back to look in the whole domain if there is no local service available.
Additionally clients have to find out about which site they belong to. This must be done dynamically because clients might move from one location to a different one on regular basis (roaming users). For this a special LDAP request, the (C)LDAP ping (http://msdn.microsoft.com/en-us/library/cc223811.aspx), was introduced.
=== Overview view of the solution ===
A new request should be added to the sssd resolver code which can do site aware lookups of DNS service records. This request will do the following steps:
1. do a DNS lookup to find any DC
1. send a CLDAP ping to the returned DC to get the client's site
1. lookup the requested service in the client's site
1. if this fails, lookup the requested service in the next nearest site if available (only available in domains with functional level 2008 or higher)
1. if this fails, lookup the requested service in the 'Default-First-Site-Name' site if it wasn't one of the previously used sites
1. if this fails, lookup the requested service without any site extension
1. if this fails the request will ultimately fail
The results of the different step should be available with one of the debug levels reserved for tracing to make debugging easier and to allow acceptance tests to validate the behavior with the help of the debug logs.
=== Implementation details ===
Currently the request to look up service records if defined by
{{{
struct tevent_req *resolv_getsrv_send(TALLOC_CTX *mem_ctx,
struct tevent_context *ev,
struct resolv_ctx *ctx,
const char *query);
int resolv_getsrv_recv(TALLOC_CTX *mem_ctx,
struct tevent_req *req,
int *status,
int *timeouts,
struct ares_srv_reply **reply_list);
}}}
from async_resolv.h.
The new request might have the following interface:
{{{
/**
* @brief Create an async request to lookup DNS service records and respect the AD DNS sites
*
* @param[in] mem_ctx Talloc memory context for the returned tevent_req structure
* @param[in] ev Tevent context
* @param[in] ctx Resolver context
* @param[in] site_ctx Site related context, may be NULL. If site_ctx is NULL resolv_getsrv_site_send() tries to resolve the site the client belongs to first and then tries to find the nearest server for the requested service.
* @param[in] service the service which should be found, e.g. _ldap._tcp
* @param[in] domain the domain where the service should be found
*
* @return
* - tevent_req structure for the new request
* - NULL if a new request could not be allocated
*/
struct tevent_req *resolv_getsrv_site_send(TALLOC_CTX *mem_ctx,
struct tevent_context *ev,
struct resolv_ctx *ctx,
struct site_ctx *site_ctx,
const char *service,
const char *domain);
/**
* @brief Return the results of the given resolv_getsrv_site request
*
* @param[in] mem_ctx Talloc memory context for the returned results
* @param[in] req resolv_getsrv_site request which should be checked
* @param[out] status the returned status of the underlying c-ares request, see area_query(3) for details
* @param[out] timeouts the number of timeout occured during the underlying c-ares request, see area_query(3) for details
* @param[out] site_ctx an opaque struct with site information which can be used in later requests to skip the site lookup
* @param[out] reply_list list of replies
*
* @return
* - 0 (EOK) on success
* - !=0 in case of an error
*/
int resolv_getsrv_site_recv(TALLOC_CTX *mem_ctx,
struct tevent_req *req,
int *status,
int *timeouts,
struct site_ctx **site_ctx,
struct ares_srv_reply **reply_list);
}}}
==== Finding a DC for the CLDAP ping ====
To find any DC in the domain a Windows client, and samba as well, look for a _ldap._tcp service record. The only difference is that samba uses a plain _ldap._tcp.domain.name while a Windows client _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.domain.name. I guess it will fall back to _ldap._tcp.domain.name if the other name cannot be resolved. I would suggest to use _ldap._tcp.domain.name for the SSSD implementation.
==== Sending the CLDAP ping ====
The CLDAP ping is a LDAP search request with a filter like
{{{
(&(&(DnsDomain=ad.domain)(DomainSid=S-1-5-21-1111-2222-3333))(NtVer=0x01000016))
}}}
and the attribute "!NetLogon".
The flags given with the !NtVer component of the search filter will be different for a domain member (AD provider) and an IPA server in an environment with trusts (IPA provider).
A domain member will belong to a site and the following flags from /usr/include/samba-4.0/gen_ndr/nbt.h should be used 'NETLOGON_NT_VERSION_5 | NETLOGON_NT_VERSION_5EX | NETLOGON_NT_VERSION_IP'. A trusted server does not belong to one of the sites of trusting domain so it can only ask for the closest site with 'NETLOGON_NT_VERSION_5 | NETLOGON_NT_VERSION_5EX | NETLOGON_NT_VERSION_WITH_CLOSEST_SITE'. Maybe NETLOGON_NT_VERSION_WITH_CLOSEST_SITE is useful for a domain member as well if e.g. the services on the local site are not available.
==== Parsing the server response ====
The server response is a single attribute "!NetLogon" which is a binary blob containing multiple NDR encoded values. This value can be decoded with ndr_pull_netlogon_samlogon_response() from the Samba library libndr-nbt.
=== How to test ===
If this feature is tested the following scenarios can be considered:
==== AD domain does not have any sites other than the default 'Default-First-Site-Name' ====
* SSSD should be able to discover the default site 'Default-First-Site-Name'
* SSSD should connect to any DC.
==== AD domain has sites but the local site of the SSSD client has no domain controller ====
* SSSD should be able to discover the local site
* SSSD should connect to a DC from 'Default-First-Site-Name'
==== AD domain has sites and the local site of the SSSD client has a domain controller ====
* SSSD should be able to discover the local site
* SSSD should connect to a DC from the local site
Besides inspection the log files with a high debug level to connection to the domain controller can also be verified with the netstat or ss utilities.
=== Author(s) ===
Sumit Bose <sbose(a)redhat.com>
11 years