Infrastructure
  1. Infrastructure
  2. INFRA-4639

Allow anonymous access to the asf-icla-publicname property in LDAP

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Fix Version/s: Initial Clearing
    • Component/s: LDAP
    • Labels:
      None

      Description

      In order to complete INFRA-4638 it would be helpful if the asf-icla-publicname property in our LDAP directory was readable by anonymous clients. Currently that's not the case even though the contents of the property are publicly visible at http://people.apache.org/committer-index.html.

        Issue Links

          Activity

          Hide
          #asfinfra IRC Bot added a comment -
          <danielsh> ldapsearch -xLLLb $searchbase retrieves the propvalue on the jail. The remainder can go on INFRA-4638
          Show
          #asfinfra IRC Bot added a comment - <danielsh> ldapsearch -xLLLb $searchbase retrieves the propvalue on the jail. The remainder can go on INFRA-4638
          Hide
          #asfinfra IRC Bot added a comment -
          <danielsh> If you write a script that parses iclas.txt and sets the attr, Tony or I will run it :) (also feel free to join IRC if you have more questions tonight)
          Show
          #asfinfra IRC Bot added a comment - <danielsh> If you write a script that parses iclas.txt and sets the attr, Tony or I will run it :) (also feel free to join IRC if you have more questions tonight)
          Hide
          Jukka Zitting added a comment -
          Getting the bits to LDAP would be great, as currently I'm using my personal karma to access the iclas.txt for generating the authors.txt file on git.apache.org. I really would like to replace that with a script that at most needs a role account for accessing the information.
          Show
          Jukka Zitting added a comment - Getting the bits to LDAP would be great, as currently I'm using my personal karma to access the iclas.txt for generating the authors.txt file on git.apache.org. I really would like to replace that with a script that at most needs a role account for accessing the information.
          Hide
          #asfinfra IRC Bot added a comment -
          <danielsh> The public names live in iclas.txt and it is planned to migrate them to ldap. Let's just migrate them to LDAP now then.
          Show
          #asfinfra IRC Bot added a comment - <danielsh> The public names live in iclas.txt and it is planned to migrate them to ldap. Let's just migrate them to LDAP now then.
          Hide
          Jukka Zitting added a comment -
          > You made the flawed assumption that these records were populated.

          Ah, that explains, thanks!

          If this information isn't yet in LDAP, then perhaps INFRA-4638 needs to be implemented in some other way. Do you know where does http://people.apache.org/committer-index.html get it's information from?
          Show
          Jukka Zitting added a comment - > You made the flawed assumption that these records were populated. Ah, that explains, thanks! If this information isn't yet in LDAP, then perhaps INFRA-4638 needs to be implemented in some other way. Do you know where does http://people.apache.org/committer-index.html get it's information from?
          Hide
          #asfinfra IRC Bot added a comment -
          <danielsh> juse use 'ldapsearch -x'. It'll work once the attribute is populated
          Show
          #asfinfra IRC Bot added a comment - <danielsh> juse use 'ldapsearch -x'. It'll work once the attribute is populated
          Hide
          Jukka Zitting added a comment -
          I don't need the LDAP service publicly available. I just need something I can use on git-wip-us for INFRA-4638.
          Show
          Jukka Zitting added a comment - I don't need the LDAP service publicly available. I just need something I can use on git-wip-us for INFRA-4638 .
          Hide
          #asfinfra IRC Bot added a comment -
          <pctony> No, those results are not weird. You made the flawed assumption that these records were populated. They aren't yet.
          Show
          #asfinfra IRC Bot added a comment - <pctony> No, those results are not weird. You made the flawed assumption that these records were populated. They aren't yet.
          Hide
          #asfinfra IRC Bot added a comment -
          <pctony> jukka if we create a role account you would have to secure those crednetials yourself. As for the data being public, it might be, but our LDAP service is not. It is an internal service for the foundation. We do not, and will not expose it externally, and allowing anonymous access just allows service accounts on local machines to access the data too (such as www-data on Ubuntu VMs)
          Show
          #asfinfra IRC Bot added a comment - <pctony> jukka if we create a role account you would have to secure those crednetials yourself. As for the data being public, it might be, but our LDAP service is not. It is an internal service for the foundation. We do not, and will not expose it externally, and allowing anonymous access just allows service accounts on local machines to access the data too (such as www-data on Ubuntu VMs)
          Hide
          Jukka Zitting added a comment -
          Hmm, this is weird:

              [jukka@tyr ~]$ ldapsearch -x -LLL '(&(uid=*)(asf-icla-publicname=*))' uid cn asf-icla-publicname
              dn: uid=pctony,ou=people,dc=apache,dc=org
              uid: pctony
              cn: Tony Stevenson
              asf-icla-publicname: Tony Stevenson

          No other results.
          Show
          Jukka Zitting added a comment - Hmm, this is weird:     [ jukka@tyr ~]$ ldapsearch -x -LLL '(&(uid=*)(asf-icla-publicname=*))' uid cn asf-icla-publicname     dn: uid=pctony,ou=people,dc=apache,dc=org     uid: pctony     cn: Tony Stevenson     asf-icla-publicname: Tony Stevenson No other results.
          Hide
          #asfinfra IRC Bot added a comment -
          <pctony> This data is still going to remain non-anonymous access only. But you can now obtain the list you want.
          Show
          #asfinfra IRC Bot added a comment - <pctony> This data is still going to remain non-anonymous access only. But you can now obtain the list you want.
          Hide
          Jukka Zitting added a comment -
          The above example was from git-wip-us (i.e. tyr.zones).

          Let's phrase this differently: I wan't an LDAP query that gives me the uid and asf-icla-publicname properties of all Apache committers. Ideally the query should work without having to worry about securing access credentials (this is all public information). If that's not possible, is there a role account I can use for the query and how should I manage the required credentials?
          Show
          Jukka Zitting added a comment - The above example was from git-wip-us (i.e. tyr.zones). Let's phrase this differently: I wan't an LDAP query that gives me the uid and asf-icla-publicname properties of all Apache committers. Ideally the query should work without having to worry about securing access credentials (this is all public information). If that's not possible, is there a role account I can use for the query and how should I manage the required credentials?
          Hide
          #asfinfra IRC Bot added a comment -
          <pctony> jukka If you want to only return accounts with this attr you need this -- "ldapsearch -x -LLL '(&(uid=*)(asf-icla-publicname=*))' uid cn asf-icla-publicname" This will return only accounts with an RDN of uid= (again, real people only), then of those display only those with the asf-icla-publicname set. Then only show the uid, cn and the asf-icla-publicname attrs and values.
          Show
          #asfinfra IRC Bot added a comment - <pctony> jukka If you want to only return accounts with this attr you need this -- "ldapsearch -x -LLL '(&(uid=*)(asf-icla-publicname=*))' uid cn asf-icla-publicname" This will return only accounts with an RDN of uid= (again, real people only), then of those display only those with the asf-icla-publicname set. Then only show the uid, cn and the asf-icla-publicname attrs and values.
          Hide
          #asfinfra IRC Bot added a comment -
          <pctony> jukka the -x is needed on all machines except for people.apache.org (due to it's NSS config). So yes, in fact it does affect your output significantly.
          Show
          #asfinfra IRC Bot added a comment - <pctony> jukka the -x is needed on all machines except for people.apache.org (due to it's NSS config). So yes, in fact it does affect your output significantly.
          Hide
          #asfinfra IRC Bot added a comment -
          <pctony> jukka your first query will return all object whose RDN is uid, in our case all real people (not service accounts). It doesnt list only people with the attribute. You need a much more complex search than that to achieve that. Your seconf query will once again list all users, and then optionally display the cn RDN if it exists (and it should for all our users.)
          Show
          #asfinfra IRC Bot added a comment - <pctony> jukka your first query will return all object whose RDN is uid, in our case all real people (not service accounts). It doesnt list only people with the attribute. You need a much more complex search than that to achieve that. Your seconf query will once again list all users, and then optionally display the cn RDN if it exists (and it should for all our users.)
          Hide
          Jukka Zitting added a comment -
          Hmm, interesting. However, compare the following:

              $ ldapsearch -LLL '(uid=*)' asf-icla-publicname
              ... list of users without asf-icla-publicname information ...

              $ ldapsearch -LLL '(uid=*)' cn
              ... list of users with cn information ...

          Adding the -x option doesn't affect the output of the above commands.

          So if I understand correctly, it would already be possible for me to first get a list of all uid's and then get their asf-icla-publicnames one by one with separate LDAP requests. Though it would be nicer if all that information was available as the result of just a single query.
          Show
          Jukka Zitting added a comment - Hmm, interesting. However, compare the following:     $ ldapsearch -LLL '(uid=*)' asf-icla-publicname     ... list of users without asf-icla-publicname information ...     $ ldapsearch -LLL '(uid=*)' cn     ... list of users with cn information ... Adding the -x option doesn't affect the output of the above commands. So if I understand correctly, it would already be possible for me to first get a list of all uid's and then get their asf-icla-publicnames one by one with separate LDAP requests. Though it would be nicer if all that information was available as the result of just a single query.
          Hide
          Tony Stevenson added a comment -
          Closing as WontFix. We don't allow true anonymous access to the data, but we do allow any valid ASF LDAP user to view the data.
          Show
          Tony Stevenson added a comment - Closing as WontFix. We don't allow true anonymous access to the data, but we do allow any valid ASF LDAP user to view the data.
          Hide
          Tony Stevenson added a comment -
          ## Make a user icla-publicname writable by 'self' and readable by
          ## any authenticated user.
          access to dn.subtree="ou=people,dc=apache,dc=org"
            attrs=asf-icla-publicname
             by self write
             ...
             by * read
             by anonymous auth


          This means that any logged in user, that is configured for LDAP (i.e. people.apache.org) can access this record.
          We dont have true anonymous access to any data, they are often forced to auth at a minimum, some are explicitly denied see the ACL here - https://svn.apache.org/repos/infra/infrastructure/trunk/ldap/conf/shared/ldap_acl.conf

          Show
          Tony Stevenson added a comment - ## Make a user icla-publicname writable by 'self' and readable by ## any authenticated user. access to dn.subtree="ou=people,dc=apache,dc=org"   attrs=asf-icla-publicname    by self write    ...    by * read    by anonymous auth This means that any logged in user, that is configured for LDAP (i.e. people.apache.org) can access this record. We dont have true anonymous access to any data, they are often forced to auth at a minimum, some are explicitly denied see the ACL here - https://svn.apache.org/repos/infra/infrastructure/trunk/ldap/conf/shared/ldap_acl.conf
          Hide
          Tony Stevenson added a comment -
          ldapsearch -LLL -x uid=pctony asf-icla-publicname
          dn: uid=pctony,ou=people,dc=apache,dc=org
          asf-icla-publicname: Tony Stevenson

          Show
          Tony Stevenson added a comment - ldapsearch -LLL -x uid=pctony asf-icla-publicname dn: uid=pctony,ou=people,dc=apache,dc=org asf-icla-publicname: Tony Stevenson
          Hide
          #asfinfra IRC Bot added a comment -
          <danielsh> s/cn=/uid=/
          Show
          #asfinfra IRC Bot added a comment - <danielsh> s/cn=/uid=/
          Hide
          Tony Stevenson added a comment -
          'ldapsearch -LLL -x cn=$uid asf-icla-publicname'
          Show
          Tony Stevenson added a comment - 'ldapsearch -LLL -x cn=$uid asf-icla-publicname'
          Hide
          Jukka Zitting added a comment -
          From within a jail I can access for example the "uid" and "cn" properties with an anonymous bind (i.e. I don't need to keep track of explicit credentials). It would be great if also the "asf-icla-publicname" was available that way as it's more appropriate than "cn" for being exposed publicly through INFRA-4638.
          Show
          Jukka Zitting added a comment - From within a jail I can access for example the "uid" and "cn" properties with an anonymous bind (i.e. I don't need to keep track of explicit credentials). It would be great if also the "asf-icla-publicname" was available that way as it's more appropriate than "cn" for being exposed publicly through INFRA-4638 .
          Hide
          #asfinfra IRC Bot added a comment -
          <pctony> Jukka, 'ldapsearch -x' works on the jail
          Show
          #asfinfra IRC Bot added a comment - <pctony> Jukka, 'ldapsearch -x' works on the jail
          Hide
          #asfinfra IRC Bot added a comment -
          <pctony> Jukka, define anonymous - do you mean publicly?
          Show
          #asfinfra IRC Bot added a comment - <pctony> Jukka, define anonymous - do you mean publicly?

            People

            • Assignee:
              Unassigned
              Reporter:
              Jukka Zitting
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development