Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On Tue, 2015-03-10 at 19:24 +0100, Petr Spacek wrote: > On 10.3.2015 18:36, Simo Sorce wrote: > > On Tue, 2015-03-10 at 18:26 +0100, Petr Spacek wrote: > >> On 10.3.2015 17:35, Simo Sorce wrote: > >>> On Tue, 2015-03-10 at 16:19 +0100, Petr Spacek wrote: > On 10.3.2015 15:53, Simo Sorce wrote: > > On Tue, 2015-03-10 at 15:32 +0100, Petr Spacek wrote: > >> Hello, > >> > >> I would like to discuss Generic support for unknown DNS RR types (RFC > >> 3597 > >> [0]). Here is the proposal: > >> > >> LDAP schema > >> === > >> - 1 new attribute: > >> ( NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' > >> EQUALITY > >> caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > >> > >> The attribute should be added to existing idnsRecord object class as > >> MAY. > >> > >> This new attribute should contain data encoded according to RFC 3597 > >> section > >> 5 [5]: > >> > >> The RDATA section of an RR of unknown type is represented as a > >>sequence of white space separated words as follows: > >> > >> The special token \# (a backslash immediately followed by a hash > >> sign), which identifies the RDATA as having the generic encoding > >> defined herein rather than a traditional type-specific encoding. > >> > >> An unsigned decimal integer specifying the RDATA length in > >> octets. > >> > >> Zero or more words of hexadecimal data encoding the actual RDATA > >> field, each containing an even number of hexadecimal digits. > >> > >>If the RDATA is of zero length, the text representation contains > >> only > >>the \# token and the single zero representing the length. > >> > >> Examples from RFC: > >> a.example. CLASS32 TYPE731 \# 6 abcd ( > >>ef 01 23 45 ) > >> b.example. HS TYPE62347 \# 0 > >> e.example. IN A \# 4 0A01 > >> e.example. CLASS1 TYPE1 10.0.0.2 > >> > >> > >> Open questions about LDAP format > >> > >> Should we include "\#" constant? We know that the attribute contains > >> record in > >> RFC 3597 syntax so it is not strictly necessary. > >> > >> I think it would be better to follow RFC 3597 format. It allows blind > >> copy&pasting from other tools, including direct calls to python-dns. > >> > >> It also eases writing conversion tools between DNS and LDAP format > >> because > >> they do not need to change record values. > >> > >> > >> Another question is if we should explicitly include length of data > >> represented > >> in hexadecimal notation as a decimal number. I'm very strongly > >> inclined to let > >> it there because it is very good sanity check and again, it allows us > >> to > >> re-use existing tools including parsers. > >> > >> I will ask Uninett.no for standardization after we sort this out (they > >> own the > >> OID arc we use for DNS records). > >> > >> > >> Attribute usage > >> === > >> Every DNS RR type has assigned a number [1] which is used on wire. RR > >> types > >> which are unknown to the server cannot be named by their mnemonic/type > >> name > >> because server would not be able to do name->number conversion and to > >> generate > >> DNS wire format. > >> > >> As a result, we have to encode the RR type number somehow. Let's use > >> attribute > >> sub-types. > >> > >> E.g. a record with type 65280 and hex value 0A01 will be > >> represented as: > >> GenericRecord;TYPE65280: \# 4 0A01 > >> > >> > >> CLI > >> === > >> $ ipa dnsrecord-add zone.example owner \ > >> --generic-type=65280 --generic-data='\# 4 0A01' > >> > >> $ ipa dnsrecord-show zone.example owner > >> Record name: owner > >> TYPE65280 Record: \# 4 0A01 > >> > >> > >> ACK? :-) > > > > Almost. > > We should refrain from using subtypes when not necessary, and in this > > case it is not necessary. > > > > Use: > > GenericRecord: 65280 \# 4 0A01 > > I was considering that too but I can see two main drawbacks: > > 1) It does not work very well with DS ACI (targetattrfilter, anyone?). > Adding > generic write access to GenericRecord == ability to add TLSA records too, > which you may not want. IMHO it is perfectly reasonable to limit write > access > to certain types (e.g. to one from private range). > > 2) We would need a separate substring index for emulating filters like > (type==65280). AFAIK GenericRecord;TYPE65280 should work
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On 10.3.2015 18:36, Simo Sorce wrote: > On Tue, 2015-03-10 at 18:26 +0100, Petr Spacek wrote: >> On 10.3.2015 17:35, Simo Sorce wrote: >>> On Tue, 2015-03-10 at 16:19 +0100, Petr Spacek wrote: On 10.3.2015 15:53, Simo Sorce wrote: > On Tue, 2015-03-10 at 15:32 +0100, Petr Spacek wrote: >> Hello, >> >> I would like to discuss Generic support for unknown DNS RR types (RFC >> 3597 >> [0]). Here is the proposal: >> >> LDAP schema >> === >> - 1 new attribute: >> ( NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' EQUALITY >> caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) >> >> The attribute should be added to existing idnsRecord object class as MAY. >> >> This new attribute should contain data encoded according to RFC 3597 >> section >> 5 [5]: >> >> The RDATA section of an RR of unknown type is represented as a >>sequence of white space separated words as follows: >> >> The special token \# (a backslash immediately followed by a hash >> sign), which identifies the RDATA as having the generic encoding >> defined herein rather than a traditional type-specific encoding. >> >> An unsigned decimal integer specifying the RDATA length in octets. >> >> Zero or more words of hexadecimal data encoding the actual RDATA >> field, each containing an even number of hexadecimal digits. >> >>If the RDATA is of zero length, the text representation contains only >>the \# token and the single zero representing the length. >> >> Examples from RFC: >> a.example. CLASS32 TYPE731 \# 6 abcd ( >>ef 01 23 45 ) >> b.example. HS TYPE62347 \# 0 >> e.example. IN A \# 4 0A01 >> e.example. CLASS1 TYPE1 10.0.0.2 >> >> >> Open questions about LDAP format >> >> Should we include "\#" constant? We know that the attribute contains >> record in >> RFC 3597 syntax so it is not strictly necessary. >> >> I think it would be better to follow RFC 3597 format. It allows blind >> copy&pasting from other tools, including direct calls to python-dns. >> >> It also eases writing conversion tools between DNS and LDAP format >> because >> they do not need to change record values. >> >> >> Another question is if we should explicitly include length of data >> represented >> in hexadecimal notation as a decimal number. I'm very strongly inclined >> to let >> it there because it is very good sanity check and again, it allows us to >> re-use existing tools including parsers. >> >> I will ask Uninett.no for standardization after we sort this out (they >> own the >> OID arc we use for DNS records). >> >> >> Attribute usage >> === >> Every DNS RR type has assigned a number [1] which is used on wire. RR >> types >> which are unknown to the server cannot be named by their mnemonic/type >> name >> because server would not be able to do name->number conversion and to >> generate >> DNS wire format. >> >> As a result, we have to encode the RR type number somehow. Let's use >> attribute >> sub-types. >> >> E.g. a record with type 65280 and hex value 0A01 will be represented >> as: >> GenericRecord;TYPE65280: \# 4 0A01 >> >> >> CLI >> === >> $ ipa dnsrecord-add zone.example owner \ >> --generic-type=65280 --generic-data='\# 4 0A01' >> >> $ ipa dnsrecord-show zone.example owner >> Record name: owner >> TYPE65280 Record: \# 4 0A01 >> >> >> ACK? :-) > > Almost. > We should refrain from using subtypes when not necessary, and in this > case it is not necessary. > > Use: > GenericRecord: 65280 \# 4 0A01 I was considering that too but I can see two main drawbacks: 1) It does not work very well with DS ACI (targetattrfilter, anyone?). Adding generic write access to GenericRecord == ability to add TLSA records too, which you may not want. IMHO it is perfectly reasonable to limit write access to certain types (e.g. to one from private range). 2) We would need a separate substring index for emulating filters like (type==65280). AFAIK GenericRecord;TYPE65280 should work with presence index which will be handy one day when we decide to handle upgrades like GenericRecord;TYPE256->UriRecord. Another (less important) annoyance is that conversion tools would have to mangle record data instead of just converting attribute name->record type. I can be convinced that subtypes
Re: [Freeipa-devel] Time-based account policies
On 03/10/2015 12:56 PM, Alexander Bokovoy wrote: > See my answer to John. We don't need to end up with iCal at all since > iCal doesn't have procedural definitions of holidays. It has > EXDATE/RRULE allowing to express exceptions and repeating rules (EXRULE > for exception rules was removed in RFC5545 and is not used anymore) but > nothing more concrete. > > RFC5545 does define multiple things which are part of iCalendar format > and which we don't really need to deal with in SSSD so we don't need > full iCal at all. We need to be able to represent recurring events and > some of exceptions to them within the rules but that is a subset of what > is needed and can be implemented without involving a fully-compliant > iCal library. I always get a bit concerned when I hear we'll factor out or just import only the minimal code we need to support the minimal functionality we need from an otherwise large complex body of code implementing an entire RFC. Maybe the code in libical is perfectly suited to extracting the snippets we need (I don't know) but experience tells me complex code has complex inter-dependencies and reducing libical to our minimal requirements might be a significant effort. Is there really a problem with just linking with the entire libical library even if it's more than we need? -- John -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Purpose of default user group
On Tue, 10 Mar 2015, Simo Sorce wrote: On Tue, 2015-03-10 at 16:01 +0100, Jakub Hrozek wrote: On Tue, Mar 10, 2015 at 03:52:44PM +0100, Martin Kosek wrote: > On 03/10/2015 03:27 PM, Rob Crittenden wrote: > > Petr Vobornik wrote: > >> Hi, > >> > >> I would like to ask what is a purpose of a default user group - by > >> default ipausers? Default group is also a required field in ipa config. > > > > To be able to apply some (undefined) group policy to all users. I'm not > > aware that it has ever been used for this. > > I would also interested in the use cases, especially given all the pain we have > with ipausers and large user bases. Especially that for current policies (SUDO, > HBAC, SELinux user policy), we always have other means to specify "all users". yes, but those means usually specify both AD and IPA users, right? I always thought "ipausers" is a handy shortcut for selecting IPA users only and not AD users. We should probably turn ipausers into a fully virtual group that is added to the user's Authorization data in the KDC (MS-PAC or in future PAD). This way it will be possible to reference it in sssd but will not create issues with memberships in the server. But we need the PAD first, I guess. (we could do something with authentication indicators too, but that would be a hack). Yep. If we need ipausers for POSIX context interpretation on IPA clients, PAD would be our choice as we already do with MS-PAC for AD users. Within LDAP server, if we want to address all IPA users to do some mass operations on them, I think we probably should have some specialized control that would give 389-ds chance to optimize on building this list of users before applying an operation to them. This would be something non-standard but more efficient than what we are doing right now. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, 10 Mar 2015, Martin Kosek wrote: On 03/10/2015 05:18 PM, Alexander Bokovoy wrote: On Tue, 10 Mar 2015, John Dennis wrote: On 03/10/2015 11:06 AM, Jakub Hrozek wrote: We may need to use libraries for processing iCal rules, like libical (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)... Is that what Alexander said, though? In his reply, I see: "Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule". I don't think iCal dependency is something we want in SSSD, the rules should be converted from iCal to SSSD format in a layer atop libipa_hbac.. But doesn't the iCal rule have to be evaluated in SSSD? If so that requires linking against libical, right? That's why I'm saying we import iCal in IPA, not that we keep using iCal as internal representation of time/date information for HBAC rules. I don't really want to impose iCal horror on HBAC rule parsing engine. I believe we can do simpler and better, given HBAC is all about ALLOW rules on the base of default DENY action. Ok, but how do you want to define rule as "Allow Joe to log in every Monday, except holidays (when the office is closed)"? We can't just have IPA processed the Ical and generate Allow ranges as there is indefinite number of the allow ranges. So if you want to described more complex rule (reocurring rule with some exceptions maybe), you end up with iCal anyway. Or not? See my answer to John. We don't need to end up with iCal at all since iCal doesn't have procedural definitions of holidays. It has EXDATE/RRULE allowing to express exceptions and repeating rules (EXRULE for exception rules was removed in RFC5545 and is not used anymore) but nothing more concrete. RFC5545 does define multiple things which are part of iCalendar format and which we don't really need to deal with in SSSD so we don't need full iCal at all. We need to be able to represent recurring events and some of exceptions to them within the rules but that is a subset of what is needed and can be implemented without involving a fully-compliant iCal library. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On 03/10/2015 04:06 PM, Jakub Hrozek wrote: On Tue, Mar 10, 2015 at 03:47:10PM +0100, Martin Kosek wrote: This is where importing iCal is helpful because it allows you to outsource the task of creating such event to something else. Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule. However, we don't need ourselves to provide a complex UI to define such rules. Instead, we can do a simple UI to create rules plus a UI to import rules defined in iCal by some other software. The rest is visualizing HBAC time/date rules which is separate from dealing with complexity of creating or importing rules. Additionally, for iCal-based imports we can utilize participants information from the iCal to automatically set up members of the rule (based on mail attribute). Ah, makes sense to me. With all the possibilities that iCal format offers, we would more or less end up storing iCal in HBAC rules (or our own format of iCal). I am just concerned it would make a bit complex processing on SSSD side, especially in the security sensitive piece for authorization rules. We may need to use libraries for processing iCal rules, like libical (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)... Is that what Alexander said, though? In his reply, I see: "Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule". This is what kind of worried me, too. If I understand it well, this means you would have iCal events such as holidays (these were mentioned before), and you would like to generate HBAC rules based on these events. Those rules would, however, be different for each country (if this is still about holidays) and might collide among user and host groups. Therefore, you would have lots and lots of rules in the end, wouldn't you? I wonder if anyone does that. From what I've seen in AD and 389 Directory Server, time-based rules are being stored in a rather simple manner. I don't mind a more complex solution but I think such exceptions might be little too much. But I might have not understood the idea very well. I don't think iCal dependency is something we want in SSSD, the rules should be converted from iCal to SSSD format in a layer atop libipa_hbac.. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On Tue, 2015-03-10 at 16:19 +0100, Petr Spacek wrote: > On 10.3.2015 15:53, Simo Sorce wrote: > > On Tue, 2015-03-10 at 15:32 +0100, Petr Spacek wrote: > >> Hello, > >> > >> I would like to discuss Generic support for unknown DNS RR types (RFC 3597 > >> [0]). Here is the proposal: > >> > >> LDAP schema > >> === > >> - 1 new attribute: > >> ( NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' EQUALITY > >> caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > >> > >> The attribute should be added to existing idnsRecord object class as MAY. > >> > >> This new attribute should contain data encoded according to RFC 3597 > >> section > >> 5 [5]: > >> > >> The RDATA section of an RR of unknown type is represented as a > >>sequence of white space separated words as follows: > >> > >> The special token \# (a backslash immediately followed by a hash > >> sign), which identifies the RDATA as having the generic encoding > >> defined herein rather than a traditional type-specific encoding. > >> > >> An unsigned decimal integer specifying the RDATA length in octets. > >> > >> Zero or more words of hexadecimal data encoding the actual RDATA > >> field, each containing an even number of hexadecimal digits. > >> > >>If the RDATA is of zero length, the text representation contains only > >>the \# token and the single zero representing the length. > >> > >> Examples from RFC: > >> a.example. CLASS32 TYPE731 \# 6 abcd ( > >>ef 01 23 45 ) > >> b.example. HS TYPE62347 \# 0 > >> e.example. IN A \# 4 0A01 > >> e.example. CLASS1 TYPE1 10.0.0.2 > >> > >> > >> Open questions about LDAP format > >> > >> Should we include "\#" constant? We know that the attribute contains > >> record in > >> RFC 3597 syntax so it is not strictly necessary. > >> > >> I think it would be better to follow RFC 3597 format. It allows blind > >> copy&pasting from other tools, including direct calls to python-dns. > >> > >> It also eases writing conversion tools between DNS and LDAP format because > >> they do not need to change record values. > >> > >> > >> Another question is if we should explicitly include length of data > >> represented > >> in hexadecimal notation as a decimal number. I'm very strongly inclined to > >> let > >> it there because it is very good sanity check and again, it allows us to > >> re-use existing tools including parsers. > >> > >> I will ask Uninett.no for standardization after we sort this out (they own > >> the > >> OID arc we use for DNS records). > >> > >> > >> Attribute usage > >> === > >> Every DNS RR type has assigned a number [1] which is used on wire. RR types > >> which are unknown to the server cannot be named by their mnemonic/type name > >> because server would not be able to do name->number conversion and to > >> generate > >> DNS wire format. > >> > >> As a result, we have to encode the RR type number somehow. Let's use > >> attribute > >> sub-types. > >> > >> E.g. a record with type 65280 and hex value 0A01 will be represented > >> as: > >> GenericRecord;TYPE65280: \# 4 0A01 > >> > >> > >> CLI > >> === > >> $ ipa dnsrecord-add zone.example owner \ > >> --generic-type=65280 --generic-data='\# 4 0A01' > >> > >> $ ipa dnsrecord-show zone.example owner > >> Record name: owner > >> TYPE65280 Record: \# 4 0A01 > >> > >> > >> ACK? :-) > > > > Almost. > > We should refrain from using subtypes when not necessary, and in this > > case it is not necessary. > > > > Use: > > GenericRecord: 65280 \# 4 0A01 > > I was considering that too but I can see two main drawbacks: > > 1) It does not work very well with DS ACI (targetattrfilter, anyone?). Adding > generic write access to GenericRecord == ability to add TLSA records too, > which you may not want. IMHO it is perfectly reasonable to limit write access > to certain types (e.g. to one from private range). > > 2) We would need a separate substring index for emulating filters like > (type==65280). AFAIK GenericRecord;TYPE65280 should work with presence index > which will be handy one day when we decide to handle upgrades like > GenericRecord;TYPE256->UriRecord. > > Another (less important) annoyance is that conversion tools would have to > mangle record data instead of just converting attribute name->record type. > > > I can be convinced that subtypes are not necessary but I do not see clear > advantage of avoiding them. What is the problem with subtypes? Poor support by most clients, so it is generally discouraged. The problem with subtypes and ACIs though is that I think ACIs do not care about the subtype unless you explicit mention them. So perhaps bind_dyndb_ldap should refuse to use a generic type that shadows DNSSEC relevant records ? Simo. -- Simo Sorce * Red Hat, Inc * N
Re: [Freeipa-devel] Time-based account policies
On Tue, 10 Mar 2015, Gabe Alford wrote: On Tue, Mar 10, 2015 at 9:51 AM, Stanislav Láznička wrote: On 03/10/2015 04:06 PM, Jakub Hrozek wrote: On Tue, Mar 10, 2015 at 03:47:10PM +0100, Martin Kosek wrote: This is where importing iCal is helpful because it allows you to outsource the task of creating such event to something else. Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule. However, we don't need ourselves to provide a complex UI to define such rules. Instead, we can do a simple UI to create rules plus a UI to import rules defined in iCal by some other software. The rest is visualizing HBAC time/date rules which is separate from dealing with complexity of creating or importing rules. Additionally, for iCal-based imports we can utilize participants information from the iCal to automatically set up members of the rule (based on mail attribute). Ah, makes sense to me. With all the possibilities that iCal format offers, we would more or less end up storing iCal in HBAC rules (or our own format of iCal). I am just concerned it would make a bit complex processing on SSSD side, especially in the security sensitive piece for authorization rules. We may need to use libraries for processing iCal rules, like libical (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)... Is that what Alexander said, though? In his reply, I see: "Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule". This is what kind of worried me, too. If I understand it well, this means you would have iCal events such as holidays (these were mentioned before), and you would like to generate HBAC rules based on these events. Those rules would, however, be different for each country (if this is still about holidays) and might collide among user and host groups. Therefore, you would have lots and lots of rules in the end, wouldn't you? I wonder if anyone does that. From what I've seen in AD and 389 Directory Server, time-based rules are being stored in a rather simple manner. I don't mind a more complex solution but I think such exceptions might be little too much. But I might have not understood the idea very well. This is my understanding as well. If using AD as the example, there are two ways that timebased rules are configured: 1. Permit logon hours during specified timeframe on specified day(s) of the week. 2. Deny logon hours during specified timeframe on specified day(s) of the week. There is nothing about holidays. I think that implementing holidays and special exemptions should be avoided. Yep. Except that we DENY by default in HBAC rules. So we only handle ALLOW case already and there are strong reasons not to structure HBAC rules to provide DENY too. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, 10 Mar 2015, John Dennis wrote: On 03/10/2015 12:13 PM, Alexander Bokovoy wrote: HBAC rule is a tuple (user|group, host|hostgroup, service|servicegroup). This tuple would get extension representing time/date information in a multivalued attribute that would describe all time/date intervals applicable to this rule. I must be misunderstanding something. Recurrence rules yield an unbounded number of "allow" intervals. Certainly you do not want to enumerate and store all the intervals, instead you want to evaluate the rule locally and obtain a simple yes/no answer, don't you? Yes. We are not contradicting each other as there is nothing in my response quoted above that implies that description of these time/date intervals is explicit rather than functional. We really need to define the format of such description but it doesn't need to be iCal as it is. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On 03/10/2015 05:18 PM, Alexander Bokovoy wrote: > On Tue, 10 Mar 2015, John Dennis wrote: >> On 03/10/2015 11:06 AM, Jakub Hrozek wrote: We may need to use libraries for processing iCal rules, like libical (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)... >>> >>> Is that what Alexander said, though? In his reply, I see: >>> "Parsing event information would produce a rule definition we would >>> store and SSSD would apply as HBAC rule". >>> >>> I don't think iCal dependency is something we want in SSSD, the >>> rules should be converted from iCal to SSSD format in a layer atop >>> libipa_hbac.. >> >> But doesn't the iCal rule have to be evaluated in SSSD? If so that >> requires linking against libical, right? > That's why I'm saying we import iCal in IPA, not that we keep using iCal > as internal representation of time/date information for HBAC rules. > > I don't really want to impose iCal horror on HBAC rule parsing engine. > I believe we can do simpler and better, given HBAC is all about ALLOW > rules on the base of default DENY action. Ok, but how do you want to define rule as "Allow Joe to log in every Monday, except holidays (when the office is closed)"? We can't just have IPA processed the Ical and generate Allow ranges as there is indefinite number of the allow ranges. So if you want to described more complex rule (reocurring rule with some exceptions maybe), you end up with iCal anyway. Or not? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On 03/10/2015 12:13 PM, Alexander Bokovoy wrote: > HBAC rule is a tuple (user|group, host|hostgroup, service|servicegroup). > This tuple would get extension representing time/date information in a > multivalued attribute that would describe all time/date intervals > applicable to this rule. I must be misunderstanding something. Recurrence rules yield an unbounded number of "allow" intervals. Certainly you do not want to enumerate and store all the intervals, instead you want to evaluate the rule locally and obtain a simple yes/no answer, don't you? -- John -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, 10 Mar 2015, John Dennis wrote: On 03/10/2015 11:06 AM, Jakub Hrozek wrote: We may need to use libraries for processing iCal rules, like libical (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)... Is that what Alexander said, though? In his reply, I see: "Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule". I don't think iCal dependency is something we want in SSSD, the rules should be converted from iCal to SSSD format in a layer atop libipa_hbac.. But doesn't the iCal rule have to be evaluated in SSSD? If so that requires linking against libical, right? That's why I'm saying we import iCal in IPA, not that we keep using iCal as internal representation of time/date information for HBAC rules. I don't really want to impose iCal horror on HBAC rule parsing engine. I believe we can do simpler and better, given HBAC is all about ALLOW rules on the base of default DENY action. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, 10 Mar 2015, Stanislav Láznička wrote: On 03/10/2015 04:06 PM, Jakub Hrozek wrote: On Tue, Mar 10, 2015 at 03:47:10PM +0100, Martin Kosek wrote: This is where importing iCal is helpful because it allows you to outsource the task of creating such event to something else. Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule. However, we don't need ourselves to provide a complex UI to define such rules. Instead, we can do a simple UI to create rules plus a UI to import rules defined in iCal by some other software. The rest is visualizing HBAC time/date rules which is separate from dealing with complexity of creating or importing rules. Additionally, for iCal-based imports we can utilize participants information from the iCal to automatically set up members of the rule (based on mail attribute). Ah, makes sense to me. With all the possibilities that iCal format offers, we would more or less end up storing iCal in HBAC rules (or our own format of iCal). I am just concerned it would make a bit complex processing on SSSD side, especially in the security sensitive piece for authorization rules. We may need to use libraries for processing iCal rules, like libical (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)... Is that what Alexander said, though? In his reply, I see: "Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule". This is what kind of worried me, too. If I understand it well, this means you would have iCal events such as holidays (these were mentioned before), and you would like to generate HBAC rules based on these events. Those rules would, however, be different for each country (if this is still about holidays) and might collide among user and host groups. Therefore, you would have lots and lots of rules in the end, wouldn't you? It does not matter how many rules are there. SSSD caches HBAC rules per host and if rule doesn't apply, it is not downloaded and doesn't affect the host. HBAC rule is a tuple (user|group, host|hostgroup, service|servicegroup). This tuple would get extension representing time/date information in a multivalued attribute that would describe all time/date intervals applicable to this rule. HBAC rules represent ALLOW action and default is DENY so you don't need to represent holidays, they are on DENY by default. You only need to represent ALLOW here. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, Mar 10, 2015 at 9:51 AM, Stanislav Láznička wrote: > On 03/10/2015 04:06 PM, Jakub Hrozek wrote: > >> On Tue, Mar 10, 2015 at 03:47:10PM +0100, Martin Kosek wrote: >> >>> This is where importing iCal is helpful because it allows you to outsource the task of creating such event to something else. Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule. However, we don't need ourselves to provide a complex UI to define such rules. Instead, we can do a simple UI to create rules plus a UI to import rules defined in iCal by some other software. The rest is visualizing HBAC time/date rules which is separate from dealing with complexity of creating or importing rules. Additionally, for iCal-based imports we can utilize participants information from the iCal to automatically set up members of the rule (based on mail attribute). Ah, makes sense to me. >>> >>> With all the possibilities that iCal format offers, we would more or >>> less end >>> up storing iCal in HBAC rules (or our own format of iCal). I am just >>> concerned >>> it would make a bit complex processing on SSSD side, especially in the >>> security >>> sensitive piece for authorization rules. >>> >>> We may need to use libraries for processing iCal rules, like libical >>> (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)... >>> >> Is that what Alexander said, though? In his reply, I see: >> "Parsing event information would produce a rule definition we would >> store and SSSD would apply as HBAC rule". >> > This is what kind of worried me, too. If I understand it well, this means > you would have iCal events such as holidays (these were mentioned before), > and you would like to generate HBAC rules based on these events. Those > rules would, however, be different for each country (if this is still about > holidays) and might collide among user and host groups. Therefore, you > would have lots and lots of rules in the end, wouldn't you? > > I wonder if anyone does that. From what I've seen in AD and 389 Directory > Server, time-based rules are being stored in a rather simple manner. I > don't mind a more complex solution but I think such exceptions might be > little too much. But I might have not understood the idea very well. This is my understanding as well. If using AD as the example, there are two ways that timebased rules are configured: 1. Permit logon hours during specified timeframe on specified day(s) of the week. 2. Deny logon hours during specified timeframe on specified day(s) of the week. There is nothing about holidays. I think that implementing holidays and special exemptions should be avoided. Just my 2 cents. Gabe > I don't think iCal dependency is something we want in SSSD, the >> rules should be converted from iCal to SSSD format in a layer atop >> libipa_hbac.. >> >> > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Purpose of default user group
On 10.3.2015 16:55, Alexander Bokovoy wrote: > On Tue, 10 Mar 2015, Petr Spacek wrote: >> On 10.3.2015 16:01, Jakub Hrozek wrote: >>> On Tue, Mar 10, 2015 at 03:52:44PM +0100, Martin Kosek wrote: On 03/10/2015 03:27 PM, Rob Crittenden wrote: > Petr Vobornik wrote: >> Hi, >> >> I would like to ask what is a purpose of a default user group - by >> default ipausers? Default group is also a required field in ipa config. > > To be able to apply some (undefined) group policy to all users. I'm not > aware that it has ever been used for this. I would also interested in the use cases, especially given all the pain we have with ipausers and large user bases. Especially that for current policies (SUDO, HBAC, SELinux user policy), we always have other means to specify "all users". >>> >>> yes, but those means usually specify both AD and IPA users, right? >>> >>> I always thought "ipausers" is a handy shortcut for selecting IPA users >>> only and not AD users. >> >> I always thought that "ipausers" is an equivalent of "domain users" in AD >> world (compare with "Trusted domain users"). >> >> In my admin life I considered "domain users" to be useful alias for real >> authenticated user accounts (compare with "Everyone" = even unauthenticated >> access, "Authenticated users" = includes machine accounts too.) >> >> >> Moreover, getting rid of ipausers does not help with 'big groups problem' in >> any way. E.g. at university you are almost inevitably going to have groups >> like 'students' which will contain more than 90 % of users anyway. > For what use we need this distinction in IPA itself? > - ACI (permissions) have separate notion to describe > anonymous/any authenticated dichotomy > - HBAC has 'all' category for users which in HBAC context means all > authenticated users > > Where else we would need ipausers other than default POSIX group which > we are not using it for? Ah, it is not a POSIX group? Too bad. I was using AD "domain users" for file permissions so POSIX group equivalent is what I had in mind. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Purpose of default user group
On Tue, 10 Mar 2015, Petr Spacek wrote: On 10.3.2015 16:01, Jakub Hrozek wrote: On Tue, Mar 10, 2015 at 03:52:44PM +0100, Martin Kosek wrote: On 03/10/2015 03:27 PM, Rob Crittenden wrote: Petr Vobornik wrote: Hi, I would like to ask what is a purpose of a default user group - by default ipausers? Default group is also a required field in ipa config. To be able to apply some (undefined) group policy to all users. I'm not aware that it has ever been used for this. I would also interested in the use cases, especially given all the pain we have with ipausers and large user bases. Especially that for current policies (SUDO, HBAC, SELinux user policy), we always have other means to specify "all users". yes, but those means usually specify both AD and IPA users, right? I always thought "ipausers" is a handy shortcut for selecting IPA users only and not AD users. I always thought that "ipausers" is an equivalent of "domain users" in AD world (compare with "Trusted domain users"). In my admin life I considered "domain users" to be useful alias for real authenticated user accounts (compare with "Everyone" = even unauthenticated access, "Authenticated users" = includes machine accounts too.) Moreover, getting rid of ipausers does not help with 'big groups problem' in any way. E.g. at university you are almost inevitably going to have groups like 'students' which will contain more than 90 % of users anyway. For what use we need this distinction in IPA itself? - ACI (permissions) have separate notion to describe anonymous/any authenticated dichotomy - HBAC has 'all' category for users which in HBAC context means all authenticated users Where else we would need ipausers other than default POSIX group which we are not using it for? -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On 10.3.2015 16:22, Petr Vobornik wrote:
> On 03/10/2015 03:53 PM, Simo Sorce wrote:
>> On Tue, 2015-03-10 at 15:32 +0100, Petr Spacek wrote:
>>> Hello,
>>>
>>> I would like to discuss Generic support for unknown DNS RR types (RFC 3597
>>> [0]). Here is the proposal:
>>>
>>> LDAP schema
>>> ===
>>> - 1 new attribute:
>>> ( NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' EQUALITY
>>> caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>>
>>> The attribute should be added to existing idnsRecord object class as MAY.
>>>
>>> This new attribute should contain data encoded according to RFC 3597
>>> section
>>> 5 [5]:
>>>
>>> The RDATA section of an RR of unknown type is represented as a
>>> sequence of white space separated words as follows:
>>>
>>>The special token \# (a backslash immediately followed by a hash
>>>sign), which identifies the RDATA as having the generic encoding
>>>defined herein rather than a traditional type-specific encoding.
>>>
>>>An unsigned decimal integer specifying the RDATA length in octets.
>>>
>>>Zero or more words of hexadecimal data encoding the actual RDATA
>>>field, each containing an even number of hexadecimal digits.
>>>
>>> If the RDATA is of zero length, the text representation contains only
>>> the \# token and the single zero representing the length.
>>>
>>> Examples from RFC:
>>>a.example. CLASS32 TYPE731 \# 6 abcd (
>>> ef 01 23 45 )
>>>b.example. HS TYPE62347 \# 0
>>>e.example. IN A \# 4 0A01
>>>e.example. CLASS1 TYPE1 10.0.0.2
>>>
>>>
>>> Open questions about LDAP format
>>>
>>> Should we include "\#" constant? We know that the attribute contains record
>>> in
>>> RFC 3597 syntax so it is not strictly necessary.
>>>
>>> I think it would be better to follow RFC 3597 format. It allows blind
>>> copy&pasting from other tools, including direct calls to python-dns.
>>>
>>> It also eases writing conversion tools between DNS and LDAP format because
>>> they do not need to change record values.
>>>
>>>
>>> Another question is if we should explicitly include length of data
>>> represented
>>> in hexadecimal notation as a decimal number. I'm very strongly inclined to
>>> let
>>> it there because it is very good sanity check and again, it allows us to
>>> re-use existing tools including parsers.
>>>
>>> I will ask Uninett.no for standardization after we sort this out (they own
>>> the
>>> OID arc we use for DNS records).
>>>
>>>
>>> Attribute usage
>>> ===
>>> Every DNS RR type has assigned a number [1] which is used on wire. RR types
>>> which are unknown to the server cannot be named by their mnemonic/type name
>>> because server would not be able to do name->number conversion and to
>>> generate
>>> DNS wire format.
>>>
>>> As a result, we have to encode the RR type number somehow. Let's use
>>> attribute
>>> sub-types.
>>>
>>> E.g. a record with type 65280 and hex value 0A01 will be represented as:
>>> GenericRecord;TYPE65280: \# 4 0A01
>>>
>>>
>>> CLI
>>> ===
>>> $ ipa dnsrecord-add zone.example owner \
>>>--generic-type=65280 --generic-data='\# 4 0A01'
>>>
>>> $ ipa dnsrecord-show zone.example owner
>>> Record name: owner
>>> TYPE65280 Record: \# 4 0A01
>
> CLI is inconsistent with current one. We have 2 modes: structured and
> unstructured. With simo's proposal it should work better when specifying
> multiple values.
>
> we use different option name for structured mod/add and unstructured even if
> the record has only one part, it could be:
I always thought that is is just an compatibility-thing. Should we really do
that even for new records? What is the value? Especially for single-part
record types?
> $ ipa dnsrecord-add zone.example owner \
> --generic-rec={"65280 \# 4 0A01", "62347 \# 0"}
>
> $ ipa dnsrecord-add zone.example owner --structured \
> --generic-value={"65280 \# 4 0A01", "62347 \# 0"}
>
> For mod the same. If we stick with this, Web UI should be quite easy and quick
> to create.
Maybe it will be easy for developers but not for users. I do not see an
obvious way to delete all records of given generic type 62347 and not to
delete generic records of all other types.
IMHO we really should not mix "type" and "value", not at least in user
interface (even if it is one string in LDAP).
Petr^2 Spacek
>>> ACK? :-)
>>
>> Almost.
>> We should refrain from using subtypes when not necessary, and in this
>> case it is not necessary.
>>
>> Use:
>> GenericRecord: 65280 \# 4 0A01
>>
>> Done!
>>
>> Simo.
>
> +1, it would also simplify code.
>
>>
>>>
>>> Related tickets
>>> ===
>>> https://fedorahosted.org/freeipa/ticket/4939
>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/157
>>>
>>> [0] http://tools.ietf.org/html/rfc3
Re: [Freeipa-devel] [PATCHES 306-316] Automated migration tool from Winsync
On 03/09/2015 12:26 PM, Tomas Babej wrote:
Hi,
this couple of patches provides a initial implementation of the
winsync migration tool:
https://fedorahosted.org/freeipa/ticket/4524
Some parts could use some polishing, but this is a sound foundation.
Tomas
Attaching one more patch to the bundle. This one should make the winsync
tool readily available after install.
Tomas
>From f85aef188f8e03548b1acc5e2effe685c63e372b Mon Sep 17 00:00:00 2001
From: Tomas Babej
Date: Mon, 9 Mar 2015 14:33:10 +0100
Subject: [PATCH] winsync-migrate: Include the tool parts in Makefile and
friends
---
freeipa.spec.in | 2 ++
install/tools/Makefile.am | 1 +
setup.py | 1 +
3 files changed, 4 insertions(+)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index b186d9fdff31118ea4d929f024f4dc16a75b1d0b..0f5308b73f974a1e046201d148cbbbd21df7ceb7 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -660,6 +660,7 @@ fi
%{_sbindir}/ipa-upgradeconfig
%{_sbindir}/ipa-advise
%{_sbindir}/ipa-cacert-manage
+%{_sbindir}/ipa-winsync-migrate
%{_libexecdir}/certmonger/dogtag-ipa-ca-renew-agent-submit
%{_libexecdir}/certmonger/ipa-server-guard
%{_libexecdir}/ipa-otpd
@@ -688,6 +689,7 @@ fi
%dir %{python_sitelib}/ipaserver/advise
%dir %{python_sitelib}/ipaserver/advise/plugins
%dir %{python_sitelib}/ipaserver/plugins
+%dir %{python_sitelib}/ipaserver/winsync_migrate
%dir %{_libdir}/ipa/certmonger
%attr(755,root,root) %{_libdir}/ipa/certmonger/*
%dir %{_usr}/share/ipa
diff --git a/install/tools/Makefile.am b/install/tools/Makefile.am
index b791a8c748a18602f88522c3a0e3d74499700ae0..8c697748c51b25a131518f4082b30ec60d9c0fce 100644
--- a/install/tools/Makefile.am
+++ b/install/tools/Makefile.am
@@ -27,6 +27,7 @@ sbin_SCRIPTS = \
ipa-restore \
ipa-advise \
ipa-cacert-manage \
+ ipa-winsync-migrate \
$(NULL)
EXTRA_DIST = \
diff --git a/setup.py b/setup.py
index af7964d601f811ca5371db4ae0b762e3b0f5238d..6438caaf56df6dedf2ddbe9a425910a4a6df30a6 100755
--- a/setup.py
+++ b/setup.py
@@ -84,6 +84,7 @@ setup(
'ipaserver.plugins',
'ipaserver.install',
'ipaserver.install.plugins',
+'ipaserver.winsync_migrate',
],
scripts=['ipa'],
data_files = [('share/man/man1', ["ipa.1"])],
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On 03/10/2015 03:53 PM, Simo Sorce wrote:
On Tue, 2015-03-10 at 15:32 +0100, Petr Spacek wrote:
Hello,
I would like to discuss Generic support for unknown DNS RR types (RFC 3597
[0]). Here is the proposal:
LDAP schema
===
- 1 new attribute:
( NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' EQUALITY
caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The attribute should be added to existing idnsRecord object class as MAY.
This new attribute should contain data encoded according to RFC 3597 section
5 [5]:
The RDATA section of an RR of unknown type is represented as a
sequence of white space separated words as follows:
The special token \# (a backslash immediately followed by a hash
sign), which identifies the RDATA as having the generic encoding
defined herein rather than a traditional type-specific encoding.
An unsigned decimal integer specifying the RDATA length in octets.
Zero or more words of hexadecimal data encoding the actual RDATA
field, each containing an even number of hexadecimal digits.
If the RDATA is of zero length, the text representation contains only
the \# token and the single zero representing the length.
Examples from RFC:
a.example. CLASS32 TYPE731 \# 6 abcd (
ef 01 23 45 )
b.example. HS TYPE62347 \# 0
e.example. IN A \# 4 0A01
e.example. CLASS1 TYPE1 10.0.0.2
Open questions about LDAP format
Should we include "\#" constant? We know that the attribute contains record in
RFC 3597 syntax so it is not strictly necessary.
I think it would be better to follow RFC 3597 format. It allows blind
copy&pasting from other tools, including direct calls to python-dns.
It also eases writing conversion tools between DNS and LDAP format because
they do not need to change record values.
Another question is if we should explicitly include length of data represented
in hexadecimal notation as a decimal number. I'm very strongly inclined to let
it there because it is very good sanity check and again, it allows us to
re-use existing tools including parsers.
I will ask Uninett.no for standardization after we sort this out (they own the
OID arc we use for DNS records).
Attribute usage
===
Every DNS RR type has assigned a number [1] which is used on wire. RR types
which are unknown to the server cannot be named by their mnemonic/type name
because server would not be able to do name->number conversion and to generate
DNS wire format.
As a result, we have to encode the RR type number somehow. Let's use attribute
sub-types.
E.g. a record with type 65280 and hex value 0A01 will be represented as:
GenericRecord;TYPE65280: \# 4 0A01
CLI
===
$ ipa dnsrecord-add zone.example owner \
--generic-type=65280 --generic-data='\# 4 0A01'
$ ipa dnsrecord-show zone.example owner
Record name: owner
TYPE65280 Record: \# 4 0A01
CLI is inconsistent with current one. We have 2 modes: structured and
unstructured. With simo's proposal it should work better when specifying
multiple values.
we use different option name for structured mod/add and unstructured
even if the record has only one part, it could be:
$ ipa dnsrecord-add zone.example owner \
--generic-rec={"65280 \# 4 0A01", "62347 \# 0"}
$ ipa dnsrecord-add zone.example owner --structured \
--generic-value={"65280 \# 4 0A01", "62347 \# 0"}
For mod the same. If we stick with this, Web UI should be quite easy and
quick to create.
ACK? :-)
Almost.
We should refrain from using subtypes when not necessary, and in this
case it is not necessary.
Use:
GenericRecord: 65280 \# 4 0A01
Done!
Simo.
+1, it would also simplify code.
Related tickets
===
https://fedorahosted.org/freeipa/ticket/4939
https://fedorahosted.org/bind-dyndb-ldap/ticket/157
[0] http://tools.ietf.org/html/rfc3597
[1]
http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
[5] http://tools.ietf.org/html/rfc3597#section-5
--
Petr^2 Spacek
--
Petr Vobornik
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On 10.3.2015 15:53, Simo Sorce wrote: > On Tue, 2015-03-10 at 15:32 +0100, Petr Spacek wrote: >> Hello, >> >> I would like to discuss Generic support for unknown DNS RR types (RFC 3597 >> [0]). Here is the proposal: >> >> LDAP schema >> === >> - 1 new attribute: >> ( NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' EQUALITY >> caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) >> >> The attribute should be added to existing idnsRecord object class as MAY. >> >> This new attribute should contain data encoded according to RFC 3597 section >> 5 [5]: >> >> The RDATA section of an RR of unknown type is represented as a >>sequence of white space separated words as follows: >> >> The special token \# (a backslash immediately followed by a hash >> sign), which identifies the RDATA as having the generic encoding >> defined herein rather than a traditional type-specific encoding. >> >> An unsigned decimal integer specifying the RDATA length in octets. >> >> Zero or more words of hexadecimal data encoding the actual RDATA >> field, each containing an even number of hexadecimal digits. >> >>If the RDATA is of zero length, the text representation contains only >>the \# token and the single zero representing the length. >> >> Examples from RFC: >> a.example. CLASS32 TYPE731 \# 6 abcd ( >>ef 01 23 45 ) >> b.example. HS TYPE62347 \# 0 >> e.example. IN A \# 4 0A01 >> e.example. CLASS1 TYPE1 10.0.0.2 >> >> >> Open questions about LDAP format >> >> Should we include "\#" constant? We know that the attribute contains record >> in >> RFC 3597 syntax so it is not strictly necessary. >> >> I think it would be better to follow RFC 3597 format. It allows blind >> copy&pasting from other tools, including direct calls to python-dns. >> >> It also eases writing conversion tools between DNS and LDAP format because >> they do not need to change record values. >> >> >> Another question is if we should explicitly include length of data >> represented >> in hexadecimal notation as a decimal number. I'm very strongly inclined to >> let >> it there because it is very good sanity check and again, it allows us to >> re-use existing tools including parsers. >> >> I will ask Uninett.no for standardization after we sort this out (they own >> the >> OID arc we use for DNS records). >> >> >> Attribute usage >> === >> Every DNS RR type has assigned a number [1] which is used on wire. RR types >> which are unknown to the server cannot be named by their mnemonic/type name >> because server would not be able to do name->number conversion and to >> generate >> DNS wire format. >> >> As a result, we have to encode the RR type number somehow. Let's use >> attribute >> sub-types. >> >> E.g. a record with type 65280 and hex value 0A01 will be represented as: >> GenericRecord;TYPE65280: \# 4 0A01 >> >> >> CLI >> === >> $ ipa dnsrecord-add zone.example owner \ >> --generic-type=65280 --generic-data='\# 4 0A01' >> >> $ ipa dnsrecord-show zone.example owner >> Record name: owner >> TYPE65280 Record: \# 4 0A01 >> >> >> ACK? :-) > > Almost. > We should refrain from using subtypes when not necessary, and in this > case it is not necessary. > > Use: > GenericRecord: 65280 \# 4 0A01 I was considering that too but I can see two main drawbacks: 1) It does not work very well with DS ACI (targetattrfilter, anyone?). Adding generic write access to GenericRecord == ability to add TLSA records too, which you may not want. IMHO it is perfectly reasonable to limit write access to certain types (e.g. to one from private range). 2) We would need a separate substring index for emulating filters like (type==65280). AFAIK GenericRecord;TYPE65280 should work with presence index which will be handy one day when we decide to handle upgrades like GenericRecord;TYPE256->UriRecord. Another (less important) annoyance is that conversion tools would have to mangle record data instead of just converting attribute name->record type. I can be convinced that subtypes are not necessary but I do not see clear advantage of avoiding them. What is the problem with subtypes? Petr^2 Spacek > > Done! > > Simo. > >> >> Related tickets >> === >> https://fedorahosted.org/freeipa/ticket/4939 >> https://fedorahosted.org/bind-dyndb-ldap/ticket/157 >> >> [0] http://tools.ietf.org/html/rfc3597 >> [1] >> http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 >> [5] http://tools.ietf.org/html/rfc3597#section-5 >> >> -- >> Petr^2 Spacek -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, Mar 10, 2015 at 03:47:10PM +0100, Martin Kosek wrote: > > This is where importing iCal is helpful because it allows you to > > outsource the task of creating such event to something else. > > > > Parsing event information would produce a rule definition we would store > > and SSSD would apply as HBAC rule. However, we don't need ourselves to > > provide a complex UI to define such rules. Instead, we can do a simple > > UI to create rules plus a UI to import rules defined in iCal by some > > other software. The rest is visualizing HBAC time/date rules which is > > separate from dealing with complexity of creating or importing rules. > > > > Additionally, for iCal-based imports we can utilize participants > > information from the iCal to automatically set up members of the rule > > (based on mail attribute). > > > > Ah, makes sense to me. > > With all the possibilities that iCal format offers, we would more or less end > up storing iCal in HBAC rules (or our own format of iCal). I am just concerned > it would make a bit complex processing on SSSD side, especially in the > security > sensitive piece for authorization rules. > > We may need to use libraries for processing iCal rules, like libical > (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)... Is that what Alexander said, though? In his reply, I see: "Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule". I don't think iCal dependency is something we want in SSSD, the rules should be converted from iCal to SSSD format in a layer atop libipa_hbac.. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Purpose of default user group
On Tue, Mar 10, 2015 at 03:52:44PM +0100, Martin Kosek wrote: > On 03/10/2015 03:27 PM, Rob Crittenden wrote: > > Petr Vobornik wrote: > >> Hi, > >> > >> I would like to ask what is a purpose of a default user group - by > >> default ipausers? Default group is also a required field in ipa config. > > > > To be able to apply some (undefined) group policy to all users. I'm not > > aware that it has ever been used for this. > > I would also interested in the use cases, especially given all the pain we > have > with ipausers and large user bases. Especially that for current policies > (SUDO, > HBAC, SELinux user policy), we always have other means to specify "all users". yes, but those means usually specify both AD and IPA users, right? I always thought "ipausers" is a handy shortcut for selecting IPA users only and not AD users. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On Tue, 2015-03-10 at 15:32 +0100, Petr Spacek wrote: > Hello, > > I would like to discuss Generic support for unknown DNS RR types (RFC 3597 > [0]). Here is the proposal: > > LDAP schema > === > - 1 new attribute: > ( NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' EQUALITY > caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > The attribute should be added to existing idnsRecord object class as MAY. > > This new attribute should contain data encoded according to RFC 3597 section > 5 [5]: > > The RDATA section of an RR of unknown type is represented as a >sequence of white space separated words as follows: > > The special token \# (a backslash immediately followed by a hash > sign), which identifies the RDATA as having the generic encoding > defined herein rather than a traditional type-specific encoding. > > An unsigned decimal integer specifying the RDATA length in octets. > > Zero or more words of hexadecimal data encoding the actual RDATA > field, each containing an even number of hexadecimal digits. > >If the RDATA is of zero length, the text representation contains only >the \# token and the single zero representing the length. > > Examples from RFC: > a.example. CLASS32 TYPE731 \# 6 abcd ( >ef 01 23 45 ) > b.example. HS TYPE62347 \# 0 > e.example. IN A \# 4 0A01 > e.example. CLASS1 TYPE1 10.0.0.2 > > > Open questions about LDAP format > > Should we include "\#" constant? We know that the attribute contains record in > RFC 3597 syntax so it is not strictly necessary. > > I think it would be better to follow RFC 3597 format. It allows blind > copy&pasting from other tools, including direct calls to python-dns. > > It also eases writing conversion tools between DNS and LDAP format because > they do not need to change record values. > > > Another question is if we should explicitly include length of data represented > in hexadecimal notation as a decimal number. I'm very strongly inclined to let > it there because it is very good sanity check and again, it allows us to > re-use existing tools including parsers. > > I will ask Uninett.no for standardization after we sort this out (they own the > OID arc we use for DNS records). > > > Attribute usage > === > Every DNS RR type has assigned a number [1] which is used on wire. RR types > which are unknown to the server cannot be named by their mnemonic/type name > because server would not be able to do name->number conversion and to generate > DNS wire format. > > As a result, we have to encode the RR type number somehow. Let's use attribute > sub-types. > > E.g. a record with type 65280 and hex value 0A01 will be represented as: > GenericRecord;TYPE65280: \# 4 0A01 > > > CLI > === > $ ipa dnsrecord-add zone.example owner \ > --generic-type=65280 --generic-data='\# 4 0A01' > > $ ipa dnsrecord-show zone.example owner > Record name: owner > TYPE65280 Record: \# 4 0A01 > > > ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 Done! Simo. > > Related tickets > === > https://fedorahosted.org/freeipa/ticket/4939 > https://fedorahosted.org/bind-dyndb-ldap/ticket/157 > > [0] http://tools.ietf.org/html/rfc3597 > [1] > http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 > [5] http://tools.ietf.org/html/rfc3597#section-5 > > -- > Petr^2 Spacek > -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Purpose of default user group
On 03/10/2015 03:27 PM, Rob Crittenden wrote: > Petr Vobornik wrote: >> Hi, >> >> I would like to ask what is a purpose of a default user group - by >> default ipausers? Default group is also a required field in ipa config. > > To be able to apply some (undefined) group policy to all users. I'm not > aware that it has ever been used for this. I would also interested in the use cases, especially given all the pain we have with ipausers and large user bases. Especially that for current policies (SUDO, HBAC, SELinux user policy), we always have other means to specify "all users". > >> In ipa migrate-ds we also set the group to all users who are not member >> of anything. Why is it important for a user to be a member of a group? >> >> Thank you > > Every POSIX user needs a default GID. We don't create user-private > groups for migrated users. > > rob > -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On 03/10/2015 03:40 PM, Alexander Bokovoy wrote: > On Tue, 10 Mar 2015, Martin Kosek wrote: >> On 03/09/2015 07:22 PM, Alexander Bokovoy wrote: >>> On Mon, 09 Mar 2015, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: > On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: > > On Mon, 09 Mar 2015, Martin Kosek wrote: > ... > > One of bigger issues we had was lack of versatile ical format parser to > > handle calendar-like specification of events -- we need to allow > > importing these ones instead of inventing our own. > > Good point. I wonder how rigorous we want to be. iCal is a pretty powerful > calendaring format. If we want to implement full support for it, it would > be > lot of code both on server side for setting it and on client side for > evaluating it (CCing Jakub for reference). > > AD itself has much simpler UI for setting the access time, a table like > that: > http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg > > > > IIRC, they only store the bits of "can login/cannot login" for the time > slots. > That's another alternative. I don't think that's what Alexander meant, I don't think the client library should come anywhere close to the iCal format. We might want to provide a script to convert an external format, but that's about it. I thought we could simply reuse parts of the previous grammar, maybe simplified. But I agree with Nathaniel (as I stated also in the private thread) that we should use UTC where possible. >>> Yes and no. Let me go in details a bit. >>> >>> We need iCal support to allow importing events created by external >>> tools. We don't need to use it as internal format. >> >> Can you please share a bit what events you have in mind? We are talking about >> HBAC access rules, so I am not sure what you want to import. >> >> Is this for use cases like - I have a recurring Linux learning lab, I want to >> all participants to be able to log in to this system during the lab run? >> >> This may results in pretty complicated time related rules in HBAC, where you >> may need to deal with reocurrence, exceptions, etc. So far more complex than >> the AD use cases >> (http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg). >> > This is where importing iCal is helpful because it allows you to > outsource the task of creating such event to something else. > > Parsing event information would produce a rule definition we would store > and SSSD would apply as HBAC rule. However, we don't need ourselves to > provide a complex UI to define such rules. Instead, we can do a simple > UI to create rules plus a UI to import rules defined in iCal by some > other software. The rest is visualizing HBAC time/date rules which is > separate from dealing with complexity of creating or importing rules. > > Additionally, for iCal-based imports we can utilize participants > information from the iCal to automatically set up members of the rule > (based on mail attribute). > Ah, makes sense to me. With all the possibilities that iCal format offers, we would more or less end up storing iCal in HBAC rules (or our own format of iCal). I am just concerned it would make a bit complex processing on SSSD side, especially in the security sensitive piece for authorization rules. We may need to use libraries for processing iCal rules, like libical (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)... -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, 10 Mar 2015, Martin Kosek wrote: On 03/10/2015 03:34 PM, Alexander Bokovoy wrote: On Tue, 10 Mar 2015, Simo Sorce wrote: On Tue, 2015-03-10 at 14:54 +0100, Martin Kosek wrote: On 03/09/2015 09:05 PM, Nathaniel McCallum wrote: > On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote: >> On Mon, 09 Mar 2015, Simo Sorce wrote: ... >>> For some tasks 'local' is the only thing that makes sense (your >>> morning alarm clock), for other things 'UTC' is the only thing >>> that make sense (coordinated changes across multiple distributed >>> data centers). >>> >>> Implementing just one or the other is not useful. >> Correct. At this point I think we are more or less in agreement that >> we need to store time rules in UTC plus timezone correction >> information specific to the execution context (HBAC rule, host, >> etc). Handling 'UTC' rule is equivalent to selecting specific >> timezone (GMT+0, for example) so this is a case of more general (UTC >> time, timezone definiton) pairs. >> >> This timezone definition may have aliases forcing HBAC intepretation >> to use local machine defaults if needed but the general scheme stays >> the same. > > Agreed. Alexander, can you please elaborate a bit more on the idea of storing the time rules in UTC + timezone correction? I thought SSSD would take take the time zone information from the local system. The purpose is that admin can create rule like "Joe can interactively log in from 8:00 to 17:00 on all machines across the globe". You cannot store the time zone with such rule as the rule spans across several many different time zones. Right? Yes this is a rule expressed in "Local Time" which is a time-zone-less rule. Yep, and timezone info for this rule is "Local Time" which is a timezone that doesn't exist in Olson database and would be interpreted by SSSD as "default server timezone". I still do not understand. With Local Time HBAC rule, I thought that the time zone information/setting would only exist on the local machine. Maybe if you provide example of exact setting that would be stored in LDAP and what should be the implications on the clients in different time zones, I would understand better. Instead of a single time point in UTC we would have a pair (time, tzinfo) where tzinfo is just a timezone info from Olson database (tzdata). 'time' element would be expressed in UTC. We would use Olson database to find out available timezones. If tzinfo is 'Local Time', we simply record it this way in LDAP record and then SSSD on the client would parse it in such way that instead of forcing TZ to the tzinfo string it would use default /etc/localtime on the host. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, 10 Mar 2015, Martin Kosek wrote: On 03/09/2015 07:22 PM, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: > On Mon, 09 Mar 2015, Martin Kosek wrote: ... > One of bigger issues we had was lack of versatile ical format parser to > handle calendar-like specification of events -- we need to allow > importing these ones instead of inventing our own. Good point. I wonder how rigorous we want to be. iCal is a pretty powerful calendaring format. If we want to implement full support for it, it would be lot of code both on server side for setting it and on client side for evaluating it (CCing Jakub for reference). AD itself has much simpler UI for setting the access time, a table like that: http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg IIRC, they only store the bits of "can login/cannot login" for the time slots. That's another alternative. I don't think that's what Alexander meant, I don't think the client library should come anywhere close to the iCal format. We might want to provide a script to convert an external format, but that's about it. I thought we could simply reuse parts of the previous grammar, maybe simplified. But I agree with Nathaniel (as I stated also in the private thread) that we should use UTC where possible. Yes and no. Let me go in details a bit. We need iCal support to allow importing events created by external tools. We don't need to use it as internal format. Can you please share a bit what events you have in mind? We are talking about HBAC access rules, so I am not sure what you want to import. Is this for use cases like - I have a recurring Linux learning lab, I want to all participants to be able to log in to this system during the lab run? This may results in pretty complicated time related rules in HBAC, where you may need to deal with reocurrence, exceptions, etc. So far more complex than the AD use cases (http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg). This is where importing iCal is helpful because it allows you to outsource the task of creating such event to something else. Parsing event information would produce a rule definition we would store and SSSD would apply as HBAC rule. However, we don't need ourselves to provide a complex UI to define such rules. Instead, we can do a simple UI to create rules plus a UI to import rules defined in iCal by some other software. The rest is visualizing HBAC time/date rules which is separate from dealing with complexity of creating or importing rules. Additionally, for iCal-based imports we can utilize participants information from the iCal to automatically set up members of the rule (based on mail attribute). -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
Hello, I would like to discuss Generic support for unknown DNS RR types (RFC 3597 [0]). Here is the proposal: LDAP schema === - 1 new attribute: ( NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) The attribute should be added to existing idnsRecord object class as MAY. This new attribute should contain data encoded according to RFC 3597 section 5 [5]: The RDATA section of an RR of unknown type is represented as a sequence of white space separated words as follows: The special token \# (a backslash immediately followed by a hash sign), which identifies the RDATA as having the generic encoding defined herein rather than a traditional type-specific encoding. An unsigned decimal integer specifying the RDATA length in octets. Zero or more words of hexadecimal data encoding the actual RDATA field, each containing an even number of hexadecimal digits. If the RDATA is of zero length, the text representation contains only the \# token and the single zero representing the length. Examples from RFC: a.example. CLASS32 TYPE731 \# 6 abcd ( ef 01 23 45 ) b.example. HS TYPE62347 \# 0 e.example. IN A \# 4 0A01 e.example. CLASS1 TYPE1 10.0.0.2 Open questions about LDAP format Should we include "\#" constant? We know that the attribute contains record in RFC 3597 syntax so it is not strictly necessary. I think it would be better to follow RFC 3597 format. It allows blind copy&pasting from other tools, including direct calls to python-dns. It also eases writing conversion tools between DNS and LDAP format because they do not need to change record values. Another question is if we should explicitly include length of data represented in hexadecimal notation as a decimal number. I'm very strongly inclined to let it there because it is very good sanity check and again, it allows us to re-use existing tools including parsers. I will ask Uninett.no for standardization after we sort this out (they own the OID arc we use for DNS records). Attribute usage === Every DNS RR type has assigned a number [1] which is used on wire. RR types which are unknown to the server cannot be named by their mnemonic/type name because server would not be able to do name->number conversion and to generate DNS wire format. As a result, we have to encode the RR type number somehow. Let's use attribute sub-types. E.g. a record with type 65280 and hex value 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Related tickets === https://fedorahosted.org/freeipa/ticket/4939 https://fedorahosted.org/bind-dyndb-ldap/ticket/157 [0] http://tools.ietf.org/html/rfc3597 [1] http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 [5] http://tools.ietf.org/html/rfc3597#section-5 -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On 03/10/2015 03:34 PM, Alexander Bokovoy wrote: > On Tue, 10 Mar 2015, Simo Sorce wrote: >> On Tue, 2015-03-10 at 14:54 +0100, Martin Kosek wrote: >>> On 03/09/2015 09:05 PM, Nathaniel McCallum wrote: >>> > On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote: >>> >> On Mon, 09 Mar 2015, Simo Sorce wrote: >>> ... >>> >>> For some tasks 'local' is the only thing that makes sense (your >>> >>> morning alarm clock), for other things 'UTC' is the only thing >>> >>> that make sense (coordinated changes across multiple distributed >>> >>> data centers). >>> >>> >>> >>> Implementing just one or the other is not useful. >>> >> Correct. At this point I think we are more or less in agreement that >>> >> we need to store time rules in UTC plus timezone correction >>> >> information specific to the execution context (HBAC rule, host, >>> >> etc). Handling 'UTC' rule is equivalent to selecting specific >>> >> timezone (GMT+0, for example) so this is a case of more general (UTC >>> >> time, timezone definiton) pairs. >>> >> >>> >> This timezone definition may have aliases forcing HBAC intepretation >>> >> to use local machine defaults if needed but the general scheme stays >>> >> the same. >>> > >>> > Agreed. >>> >>> Alexander, can you please elaborate a bit more on the idea of storing the >>> time >>> rules in UTC + timezone correction? I thought SSSD would take take the time >>> zone information from the local system. >>> >>> The purpose is that admin can create rule like "Joe can interactively log in >>> from 8:00 to 17:00 on all machines across the globe". You cannot store the >>> time >>> zone with such rule as the rule spans across several many different time >>> zones. >>> Right? >> >> Yes this is a rule expressed in "Local Time" which is a time-zone-less >> rule. > Yep, and timezone info for this rule is "Local Time" which is a timezone > that doesn't exist in Olson database and would be interpreted by SSSD > as "default server timezone". I still do not understand. With Local Time HBAC rule, I thought that the time zone information/setting would only exist on the local machine. Maybe if you provide example of exact setting that would be stored in LDAP and what should be the implications on the clients in different time zones, I would understand better. Thanks, Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, 10 Mar 2015, Simo Sorce wrote: On Tue, 2015-03-10 at 14:54 +0100, Martin Kosek wrote: On 03/09/2015 09:05 PM, Nathaniel McCallum wrote: > On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote: >> On Mon, 09 Mar 2015, Simo Sorce wrote: ... >>> For some tasks 'local' is the only thing that makes sense (your >>> morning alarm clock), for other things 'UTC' is the only thing >>> that make sense (coordinated changes across multiple distributed >>> data centers). >>> >>> Implementing just one or the other is not useful. >> Correct. At this point I think we are more or less in agreement that >> we need to store time rules in UTC plus timezone correction >> information specific to the execution context (HBAC rule, host, >> etc). Handling 'UTC' rule is equivalent to selecting specific >> timezone (GMT+0, for example) so this is a case of more general (UTC >> time, timezone definiton) pairs. >> >> This timezone definition may have aliases forcing HBAC intepretation >> to use local machine defaults if needed but the general scheme stays >> the same. > > Agreed. Alexander, can you please elaborate a bit more on the idea of storing the time rules in UTC + timezone correction? I thought SSSD would take take the time zone information from the local system. The purpose is that admin can create rule like "Joe can interactively log in from 8:00 to 17:00 on all machines across the globe". You cannot store the time zone with such rule as the rule spans across several many different time zones. Right? Yes this is a rule expressed in "Local Time" which is a time-zone-less rule. Yep, and timezone info for this rule is "Local Time" which is a timezone that doesn't exist in Olson database and would be interpreted by SSSD as "default server timezone". -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Purpose of default user group
Petr Vobornik wrote: > Hi, > > I would like to ask what is a purpose of a default user group - by > default ipausers? Default group is also a required field in ipa config. To be able to apply some (undefined) group policy to all users. I'm not aware that it has ever been used for this. > In ipa migrate-ds we also set the group to all users who are not member > of anything. Why is it important for a user to be a member of a group? > > Thank you Every POSIX user needs a default GID. We don't create user-private groups for migrated users. rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, 2015-03-10 at 15:00 +0100, Martin Kosek wrote: > On 03/09/2015 07:22 PM, Alexander Bokovoy wrote: > > On Mon, 09 Mar 2015, Jakub Hrozek wrote: > >> On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: > >>> On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: > >>> > On Mon, 09 Mar 2015, Martin Kosek wrote: > >>> ... > >>> > One of bigger issues we had was lack of versatile ical format parser to > >>> > handle calendar-like specification of events -- we need to allow > >>> > importing these ones instead of inventing our own. > >>> > >>> Good point. I wonder how rigorous we want to be. iCal is a pretty powerful > >>> calendaring format. If we want to implement full support for it, it would > >>> be > >>> lot of code both on server side for setting it and on client side for > >>> evaluating it (CCing Jakub for reference). > >>> > >>> AD itself has much simpler UI for setting the access time, a table like > >>> that: > >>> http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg > >>> > >>> > >>> IIRC, they only store the bits of "can login/cannot login" for the time > >>> slots. > >>> That's another alternative. > >> > >> I don't think that's what Alexander meant, I don't think the client > >> library should come anywhere close to the iCal format. We might want to > >> provide a script to convert an external format, but that's about it. > >> > >> I thought we could simply reuse parts of the previous grammar, maybe > >> simplified. But I agree with Nathaniel (as I stated also in the private > >> thread) that we should use UTC where possible. > > Yes and no. Let me go in details a bit. > > > > We need iCal support to allow importing events created by external > > tools. We don't need to use it as internal format. > > Can you please share a bit what events you have in mind? We are talking about > HBAC access rules, so I am not sure what you want to import. > > Is this for use cases like - I have a recurring Linux learning lab, I want to > all participants to be able to log in to this system during the lab run? You still need this, if you really want time based rules, then pretty soon you'll get requests to add special exceptions, like holidays, and who knows what else. Last time around we came to the conclusion that this was very complicated and dropped it for that reason. A non-complicated tool is too simple to be useful, a complete one was deemed too complicated to implement. Damned if you, damned if you don't. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Tue, 2015-03-10 at 14:54 +0100, Martin Kosek wrote: > On 03/09/2015 09:05 PM, Nathaniel McCallum wrote: > > On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote: > >> On Mon, 09 Mar 2015, Simo Sorce wrote: > ... > >>> For some tasks 'local' is the only thing that makes sense (your > >>> morning alarm clock), for other things 'UTC' is the only thing > >>> that make sense (coordinated changes across multiple distributed > >>> data centers). > >>> > >>> Implementing just one or the other is not useful. > >> Correct. At this point I think we are more or less in agreement that > >> we need to store time rules in UTC plus timezone correction > >> information specific to the execution context (HBAC rule, host, > >> etc). Handling 'UTC' rule is equivalent to selecting specific > >> timezone (GMT+0, for example) so this is a case of more general (UTC > >> time, timezone definiton) pairs. > >> > >> This timezone definition may have aliases forcing HBAC intepretation > >> to use local machine defaults if needed but the general scheme stays > >> the same. > > > > Agreed. > > Alexander, can you please elaborate a bit more on the idea of storing the time > rules in UTC + timezone correction? I thought SSSD would take take the time > zone information from the local system. > > The purpose is that admin can create rule like "Joe can interactively log in > from 8:00 to 17:00 on all machines across the globe". You cannot store the > time > zone with such rule as the rule spans across several many different time > zones. > Right? Yes this is a rule expressed in "Local Time" which is a time-zone-less rule. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On 03/09/2015 07:22 PM, Alexander Bokovoy wrote: > On Mon, 09 Mar 2015, Jakub Hrozek wrote: >> On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: >>> On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: >>> > On Mon, 09 Mar 2015, Martin Kosek wrote: >>> ... >>> > One of bigger issues we had was lack of versatile ical format parser to >>> > handle calendar-like specification of events -- we need to allow >>> > importing these ones instead of inventing our own. >>> >>> Good point. I wonder how rigorous we want to be. iCal is a pretty powerful >>> calendaring format. If we want to implement full support for it, it would be >>> lot of code both on server side for setting it and on client side for >>> evaluating it (CCing Jakub for reference). >>> >>> AD itself has much simpler UI for setting the access time, a table like >>> that: >>> http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg >>> >>> >>> IIRC, they only store the bits of "can login/cannot login" for the time >>> slots. >>> That's another alternative. >> >> I don't think that's what Alexander meant, I don't think the client >> library should come anywhere close to the iCal format. We might want to >> provide a script to convert an external format, but that's about it. >> >> I thought we could simply reuse parts of the previous grammar, maybe >> simplified. But I agree with Nathaniel (as I stated also in the private >> thread) that we should use UTC where possible. > Yes and no. Let me go in details a bit. > > We need iCal support to allow importing events created by external > tools. We don't need to use it as internal format. Can you please share a bit what events you have in mind? We are talking about HBAC access rules, so I am not sure what you want to import. Is this for use cases like - I have a recurring Linux learning lab, I want to all participants to be able to log in to this system during the lab run? This may results in pretty complicated time related rules in HBAC, where you may need to deal with reocurrence, exceptions, etc. So far more complex than the AD use cases (http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg). Thanks, Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On 03/09/2015 09:05 PM, Nathaniel McCallum wrote: > On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote: >> On Mon, 09 Mar 2015, Simo Sorce wrote: ... >>> For some tasks 'local' is the only thing that makes sense (your >>> morning alarm clock), for other things 'UTC' is the only thing >>> that make sense (coordinated changes across multiple distributed >>> data centers). >>> >>> Implementing just one or the other is not useful. >> Correct. At this point I think we are more or less in agreement that >> we need to store time rules in UTC plus timezone correction >> information specific to the execution context (HBAC rule, host, >> etc). Handling 'UTC' rule is equivalent to selecting specific >> timezone (GMT+0, for example) so this is a case of more general (UTC >> time, timezone definiton) pairs. >> >> This timezone definition may have aliases forcing HBAC intepretation >> to use local machine defaults if needed but the general scheme stays >> the same. > > Agreed. Alexander, can you please elaborate a bit more on the idea of storing the time rules in UTC + timezone correction? I thought SSSD would take take the time zone information from the local system. The purpose is that admin can create rule like "Joe can interactively log in from 8:00 to 17:00 on all machines across the globe". You cannot store the time zone with such rule as the rule spans across several many different time zones. Right? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] Use curl instead of wget
On 01/22/2015 04:01 PM, Alexander Bokovoy wrote: On Thu, 22 Jan 2015, Colin Walters wrote: On Thu, Jan 22, 2015, at 08:45 AM, Alexander Bokovoy wrote: We have abstraction layer to take care of different platforms on a wider scale than just this particular binary. We are gradually moving all code to use platform abstraction to allow other platforms to be supported (like FreeBSD or Illumos) and we in general cannot guarantee things will be there at the same locations. That doesn't answer the "why not just use $PATH" part. Regardless, here's a new patch which adds a BIN_CURL. We had cases in past when a non-working from FreeIPA perspective utility was selected from $PATH due to a local misconfiguration. For something that is packaged as a complex combination of multiple packages, packaging requirements at least allow to establish the environment we expect and which was tested. Relying on $PATH doesn't improve this assumption. And some of cases are pretty subtle, like libxmlrpc-c uses cURL library and if cURL was built without GSSAPI support it will silently fail, leaving no traces at why this has happened. curl utility also doesn't check if SPNEGO support (GSSAPI in our case) was compiled in if you specify 'curl --negotiate' without any option value. From 47701a454ba442f08cd05a77ff6a2dbba76b787a Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Wed, 21 Jan 2015 16:59:52 -0500 Subject: [PATCH] Use curl instead of wget Curl has a shared library, and so ends up being used by more components of the OS. It should be preferred over wget. The motivation for this patch is for Project Atomic hosts; we want to include ipa-client, but trim down its dependencies. If wget isn't installed on the host, it doesn't need to be updated for security errata. Code-wise looks OK. We need to test it, I'll look at it next week. I see two issues with the patch: 1.) BIN_CURL does not respect the ordering of the paths (they are sorted by the values). 2.) I'm not sure the patch should touch advise/legacy_clients.py at all. That part of the code just generates a bash script, which is meant to be run on legacy clients (which have nothing to do with the Atomic effort). If we want to change this, tests in test_integration/test_advise.py need to be amended too. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 142] extdom: fix memory leak
On 03/10/2015 12:10 PM, Sumit Bose wrote:
On Tue, Mar 10, 2015 at 11:59:45AM +0100, Tomas Babej wrote:
On 03/05/2015 08:00 AM, Alexander Bokovoy wrote:
On Wed, 04 Mar 2015, Nathan Kinder wrote:
On 03/04/2015 10:34 PM, Alexander Bokovoy wrote:
On Wed, 04 Mar 2015, Sumit Bose wrote:
Hi,
while running 389ds with valgrind to see if my other patches
introduced
a memory leak I found an older one which is fixed by this patch.
bye,
Sumit
>From bb02cdc135fecc1766b17edd61554dbde9bccd0b Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Wed, 4 Mar 2015 17:53:08 +0100
Subject: [PATCH] extdom: fix memory leak
---
daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c | 1 +
1 file changed, 1 insertion(+)
diff --git
a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
index
a040f2beba073d856053429face2f464347b2524..708d0e4a2fc9da4f87a24a49c945587049f7280f
100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
@@ -156,6 +156,7 @@ done:
LOG("%s", err_msg);
}
slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL);
+ber_bvfree(ret_val);
free_req_data(req);
return SLAPI_PLUGIN_EXTENDED_SENT_RESULT;
}
I can see in 389-ds code that it actually tries to remove the value in
the end of extended operation handling:
This below code snippet is freeing the extended operation request value
(SLAPI_EXT_OP_REQ_VALUE), not the return value (SLAPI_EXT_OP_RET_VAL).
If you look at check_and_send_extended_result() in the 389-ds code,
you'll see where the extended operation return value is sent, and it
doesn't perform a free. It is up to the plug-in to perform the free. A
good example of this in the 389-ds code is in the passwd_modify_extop()
function.
Sumit's code looks good to me. ACK.
Argh. Sorry for confusion of RET vs REQ. Morning, I need coffee!
ACK.
-NGK
slapi_pblock_set( pb, SLAPI_EXT_OP_REQ_OID, extoid );
slapi_pblock_set( pb, SLAPI_EXT_OP_REQ_VALUE, &extval );
slapi_pblock_set( pb, SLAPI_REQUESTOR_ISROOT,
&pb->pb_op->o_isroot);
rc = plugin_call_exop_plugins( pb, extoid );
if ( SLAPI_PLUGIN_EXTENDED_SENT_RESULT != rc ) {
if ( SLAPI_PLUGIN_EXTENDED_NOT_HANDLED == rc ) {
lderr = LDAP_PROTOCOL_ERROR;/* no plugin
handled the op */
errmsg = "unsupported extended operation";
} else {
errmsg = NULL;
lderr = rc;
}
send_ldap_result( pb, lderr, NULL, errmsg, 0, NULL );
}
free_and_return:
if (extoid)
slapi_ch_free((void **)&extoid);
if (extval.bv_val)
slapi_ch_free((void **)&extval.bv_val);
return;
The patch does not apply to the current master branch.
Sumit, can you send a updated version?
sure, new version attached.
bye,
Sumit
Thanks,
Tomas
Thanks,
Pushed to master: 8dac096ae3a294dc55b32b69b873013fd687e945
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 142] extdom: fix memory leak
On Tue, Mar 10, 2015 at 11:59:45AM +0100, Tomas Babej wrote:
>
> On 03/05/2015 08:00 AM, Alexander Bokovoy wrote:
> >On Wed, 04 Mar 2015, Nathan Kinder wrote:
> >>
> >>
> >>On 03/04/2015 10:34 PM, Alexander Bokovoy wrote:
> >>>On Wed, 04 Mar 2015, Sumit Bose wrote:
> Hi,
>
> while running 389ds with valgrind to see if my other patches
> introduced
> a memory leak I found an older one which is fixed by this patch.
>
> bye,
> Sumit
> >>>
> From bb02cdc135fecc1766b17edd61554dbde9bccd0b Mon Sep 17 00:00:00 2001
> From: Sumit Bose
> Date: Wed, 4 Mar 2015 17:53:08 +0100
> Subject: [PATCH] extdom: fix memory leak
>
> ---
> daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
> a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
> b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
> index
> a040f2beba073d856053429face2f464347b2524..708d0e4a2fc9da4f87a24a49c945587049f7280f
>
> 100644
> --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
> +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
> @@ -156,6 +156,7 @@ done:
> LOG("%s", err_msg);
> }
> slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL);
> +ber_bvfree(ret_val);
> free_req_data(req);
> return SLAPI_PLUGIN_EXTENDED_SENT_RESULT;
> }
> >>>I can see in 389-ds code that it actually tries to remove the value in
> >>>the end of extended operation handling:
> >>
> >>This below code snippet is freeing the extended operation request value
> >>(SLAPI_EXT_OP_REQ_VALUE), not the return value (SLAPI_EXT_OP_RET_VAL).
> >>
> >>If you look at check_and_send_extended_result() in the 389-ds code,
> >>you'll see where the extended operation return value is sent, and it
> >>doesn't perform a free. It is up to the plug-in to perform the free. A
> >>good example of this in the 389-ds code is in the passwd_modify_extop()
> >>function.
> >>
> >>
> >>Sumit's code looks good to me. ACK.
> >Argh. Sorry for confusion of RET vs REQ. Morning, I need coffee!
> >
> >ACK.
> >
> >>
> >>-NGK
> >>
> >>> slapi_pblock_set( pb, SLAPI_EXT_OP_REQ_OID, extoid );
> >>> slapi_pblock_set( pb, SLAPI_EXT_OP_REQ_VALUE, &extval );
> >>> slapi_pblock_set( pb, SLAPI_REQUESTOR_ISROOT,
> >>>&pb->pb_op->o_isroot);
> >>>
> >>> rc = plugin_call_exop_plugins( pb, extoid );
> >>>
> >>> if ( SLAPI_PLUGIN_EXTENDED_SENT_RESULT != rc ) {
> >>> if ( SLAPI_PLUGIN_EXTENDED_NOT_HANDLED == rc ) {
> >>> lderr = LDAP_PROTOCOL_ERROR;/* no plugin
> >>>handled the op */
> >>> errmsg = "unsupported extended operation";
> >>> } else {
> >>> errmsg = NULL;
> >>> lderr = rc;
> >>> }
> >>> send_ldap_result( pb, lderr, NULL, errmsg, 0, NULL );
> >>> }
> >>>free_and_return:
> >>> if (extoid)
> >>> slapi_ch_free((void **)&extoid);
> >>> if (extval.bv_val)
> >>> slapi_ch_free((void **)&extval.bv_val);
> >>> return;
> >>>
> >>>
> >
>
> The patch does not apply to the current master branch.
>
> Sumit, can you send a updated version?
sure, new version attached.
bye,
Sumit
>
> Thanks,
> Tomas
From 2a14bb1a6c44a8c6f5730f97ad3239e9fca2392a Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Wed, 4 Mar 2015 17:53:08 +0100
Subject: [PATCH] extdom: fix memory leak
---
daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
index
1ea0c1320accc66235d6f1a41055de434aeacab7..dc7785877fc321ddaa5b6967d1c1b06cb454bbbf
100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
@@ -154,6 +154,7 @@ done:
LOG("%s", err_msg);
}
slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL);
+ber_bvfree(ret_val);
return SLAPI_PLUGIN_EXTENDED_SENT_RESULT;
}
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 142] extdom: fix memory leak
On 03/05/2015 08:00 AM, Alexander Bokovoy wrote:
On Wed, 04 Mar 2015, Nathan Kinder wrote:
On 03/04/2015 10:34 PM, Alexander Bokovoy wrote:
On Wed, 04 Mar 2015, Sumit Bose wrote:
Hi,
while running 389ds with valgrind to see if my other patches
introduced
a memory leak I found an older one which is fixed by this patch.
bye,
Sumit
From bb02cdc135fecc1766b17edd61554dbde9bccd0b Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Wed, 4 Mar 2015 17:53:08 +0100
Subject: [PATCH] extdom: fix memory leak
---
daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c | 1 +
1 file changed, 1 insertion(+)
diff --git
a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
index
a040f2beba073d856053429face2f464347b2524..708d0e4a2fc9da4f87a24a49c945587049f7280f
100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
@@ -156,6 +156,7 @@ done:
LOG("%s", err_msg);
}
slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL);
+ber_bvfree(ret_val);
free_req_data(req);
return SLAPI_PLUGIN_EXTENDED_SENT_RESULT;
}
I can see in 389-ds code that it actually tries to remove the value in
the end of extended operation handling:
This below code snippet is freeing the extended operation request value
(SLAPI_EXT_OP_REQ_VALUE), not the return value (SLAPI_EXT_OP_RET_VAL).
If you look at check_and_send_extended_result() in the 389-ds code,
you'll see where the extended operation return value is sent, and it
doesn't perform a free. It is up to the plug-in to perform the free. A
good example of this in the 389-ds code is in the passwd_modify_extop()
function.
Sumit's code looks good to me. ACK.
Argh. Sorry for confusion of RET vs REQ. Morning, I need coffee!
ACK.
-NGK
slapi_pblock_set( pb, SLAPI_EXT_OP_REQ_OID, extoid );
slapi_pblock_set( pb, SLAPI_EXT_OP_REQ_VALUE, &extval );
slapi_pblock_set( pb, SLAPI_REQUESTOR_ISROOT,
&pb->pb_op->o_isroot);
rc = plugin_call_exop_plugins( pb, extoid );
if ( SLAPI_PLUGIN_EXTENDED_SENT_RESULT != rc ) {
if ( SLAPI_PLUGIN_EXTENDED_NOT_HANDLED == rc ) {
lderr = LDAP_PROTOCOL_ERROR;/* no plugin
handled the op */
errmsg = "unsupported extended operation";
} else {
errmsg = NULL;
lderr = rc;
}
send_ldap_result( pb, lderr, NULL, errmsg, 0, NULL );
}
free_and_return:
if (extoid)
slapi_ch_free((void **)&extoid);
if (extval.bv_val)
slapi_ch_free((void **)&extval.bv_val);
return;
The patch does not apply to the current master branch.
Sumit, can you send a updated version?
Thanks,
Tomas
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] extdom: return LDAP_NO_SUCH_OBJECT to the client
On 03/05/2015 07:28 AM, Alexander Bokovoy wrote:
On Wed, 04 Mar 2015, Sumit Bose wrote:
Hi,
with this patch the extdom plugin will properly indicate to a client if
the search object does not exist instead of returning a generic error.
This is important for the client to act accordingly and improve
debugging possibilities.
bye,
Sumit
From 3895fa21524efc3a22bfb36b1a9aa34277b8dd46 Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Wed, 4 Mar 2015 13:39:04 +0100
Subject: [PATCH] extdom: return LDAP_NO_SUCH_OBJECT to the client
---
daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c | 8
++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
index
a70ed20f1816a7e00385edae8a81dd5dad9e9362..a040f2beba073d856053429face2f464347b2524
100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
@@ -123,8 +123,12 @@ static int ipa_extdom_extop(Slapi_PBlock *pb)
ret = handle_request(ctx, req, &ret_val);
if (ret != LDAP_SUCCESS) {
-rc = LDAP_OPERATIONS_ERROR;
-err_msg = "Failed to handle the request.\n";
+if (ret == LDAP_NO_SUCH_OBJECT) {
+rc = LDAP_NO_SUCH_OBJECT;
+} else {
+rc = LDAP_OPERATIONS_ERROR;
+err_msg = "Failed to handle the request.\n";
+}
goto done;
}
--
2.1.0
ACK.
Pushed to master: 024463804c0c73e89ed76e709a838762a8302f04
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Purpose of default user group
Hi, I would like to ask what is a purpose of a default user group - by default ipausers? Default group is also a required field in ipa config. In ipa migrate-ds we also set the group to all users who are not member of anything. Why is it important for a user to be a member of a group? Thank you -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Rename IPAv3_AD_trust_setup?
On Tue, 10 Mar 2015, Martin Kosek wrote: Hi, I just saw someone refer to [1] with respect to FreeIPA 4.x. Would it make sense to just rename the page from [1] to [2] (with keeping redirect of course)? This would move the page from Howto/ name space which we use for community HOWTO articles and move it to standard default name space. We would also not confuse people with the "v3" version, since it applies to all our FreeIPA versions, including v4. [1] http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup [2] http://www.freeipa.org/page/Active_Directory_Trust_setup I'm fine if there is a redirect. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Rename IPAv3_AD_trust_setup?
Hi, I just saw someone refer to [1] with respect to FreeIPA 4.x. Would it make sense to just rename the page from [1] to [2] (with keeping redirect of course)? This would move the page from Howto/ name space which we use for community HOWTO articles and move it to standard default name space. We would also not confuse people with the "v3" version, since it applies to all our FreeIPA versions, including v4. [1] http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup [2] http://www.freeipa.org/page/Active_Directory_Trust_setup -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
