OpenBSD Journal

KernelTrap: Who's Who At the 2006 OpenBSD Hackathon, Part II

Contributed by ben on from the whats-happening? dept.

Jeremy Andrews of KernelTrap spent some more time at the hackathon interviewing developers and asking more questions about where they are from, what they are working on at the hackathon, and what brought them to OpenBSD.

(Comments are closed)

Comments

  1. By Anonymous Coward (128.171.90.200) on

    Dale Rhan's prebinding work sounds interesting, that is to say I'll be interested in seeing how it is implemented. Good luck.

    Comments

    1. By Anonymous Coward (156.34.211.102) on

      > Dale Rhan's prebinding work sounds interesting

      Hmm ... perhaps Firefox's startup will qualify as merely 'very slow' after this addition. I'd like to hear more about it myself. I had pretty much written this off as a feature OpenBSD would never have -- it never occurred to me it could be done in a secure way.

  2. By Anonymous Coward (200.168.74.54) on

    I wonder if any of the OpenBSD developers is dedicated to a BSD licensed LDAP implementation. As any other enterprise OS, I think OpenBSD deserves to have a built in external authentication and accounting system (read nsswitch/pam/etc). My request is not to adapt nss, pam, or any other GPL'd code, but to make similar ones under a more wide license (again, BSD).

    I have lost many opportunities to install OpenBSD because of this issue and had to stick with FreeBSD, Linux or even Solaris.

    Comments

    1. By Anonymous Coward (213.5.161.18) on

      isn't kerberos sufficient (or even better)?
      it's included in the main system.

      Comments

      1. By Anonymous Coward (200.168.74.54) on

        > isn't kerberos sufficient (or even better)?
        > it's included in the main system.

        It's not as flexible as LDAP and not so common on other unixes. And normally LDAP uses Kerberos for authentication (read Active Directory).

        I thing you are mixing things.

        Comments

        1. By Anonymous Coward (66.11.66.41) on

          > > isn't kerberos sufficient (or even better)?
          > > it's included in the main system.
          >
          > It's not as flexible as LDAP and not so common on other unixes. And normally LDAP uses Kerberos for authentication (read Active Directory).
          >
          > I thing you are mixing things.
          >

          No, you are "mixing things". Kerberos is used for authentication in active directory. And in any decent unix network on the planet. Active directory stores user info in ldap, but you don't want to bind to ldap to do lookups directly for authentication, that's just dumb. Kerberos is designed specifically for authentication. And its very common, and available on every unix. Kerberos is not sufficient on its own, because you still have to add local users to every machine. This is why you want nsswitch to lookup the user info from ldap.

          Comments

          1. By Anonymous Coward (200.168.74.54) on

            > No, you are "mixing things". Kerberos is used for authentication in active directory. And in any decent unix network on the planet. Active directory stores user info in ldap, but you don't want to bind to ldap to do lookups directly for authentication, that's just dumb. Kerberos is designed specifically for authentication. And its very common, and available on every unix. Kerberos is not sufficient on its own, because you still have to add local users to every machine. This is why you want nsswitch to lookup the user info from ldap.

            Yes, I agree with you. But if you read your first post you may note that you are suggesting just krb5 and forgetting about LDAP. This is not the purpose and will not fit into a dynamic authentication system. LDAP is the way, and krb5 should be used too, if possible.

    2. By gwyllion (134.58.253.114) on

      In part 1 of the kerneltrap, Chris Kuethe says he plans to work on "LDAP lookups for user ids and passwords". I assume this is based on port/sysutils/login_ldap. Maybe you should contact him if you want to know more.

      Comments

      1. By sthen (81.168.66.226) on

        > In part 1 of the kerneltrap, Chris Kuethe says he plans to work on "LDAP lookups for user ids and passwords".

        Ah, interesting - I didn't spot that. Sounds like it might tie in nicely with his work on authpf, amongst other things.

        Comments

        1. By Anonymous Coward (200.168.74.54) on

          > Ah, interesting - I didn't spot that. Sounds like it might tie in nicely with his work on authpf, amongst other things.

          "I see isakmpdead people"

    3. By Anonymous Coward (66.11.66.41) on

      > I wonder if any of the OpenBSD developers is dedicated to a BSD licensed LDAP implementation. As any other enterprise OS, I think OpenBSD deserves to have a built in external authentication and accounting system (read nsswitch/pam/etc). My request is not to adapt nss, pam, or any other GPL'd code, but to make similar ones under a more wide license (again, BSD).
      >
      > I have lost many opportunities to install OpenBSD because of this issue and had to stick with FreeBSD, Linux or even Solaris.

      Yes, it does suck that openbsd can't be used in a typical corporate network. There was a nsswitch patch posted to tech@ a long time ago, but it was ignored by the devs.

    4. By Anonymous Coward (128.171.90.200) on

      I don't know about nsswitch, but I do know that PAM has problems with OpenSSH, or maybe thats the other way around, either way in order for it to be fully integrated it needs to work properly. I have used LDAP in a number of places, and it is fine as long as the LDAP server stays up, or else you have problems including, but not limited to, typing `whoami` and getting the response back that the system doesn't know who you are.

      Comments

      1. By Nate (65.94.99.88) on

        > I don't know about nsswitch, but I do know that PAM has problems with OpenSSH, or maybe thats the other way around, either way in order for it to be fully integrated it needs to work properly. I have used LDAP in a number of places, and it is fine as long as the LDAP server stays up, or else you have problems including, but not limited to, typing `whoami` and getting the response back that the system doesn't know who you are.
        >

        PAM as a standard is broken, since none of the implementations work the same - it's because of this that there is not a PAM in OpenBSD, instead there is BSD auth. Since OpenBSD doesn't do PAM, OpenSSH's PAM use cannot be expected to be as good as other parts of the suite

        There is no chance that PAM will ever be fully integrated as near as I can tell, because there is no such thing as PAM working properly.

        Comments

        1. By Anonymous Coward (200.168.74.54) on

          > PAM as a standard is broken, since none of the implementations work the same - it's because of this that there is not a PAM in OpenBSD, instead there is BSD auth. Since OpenBSD doesn't do PAM, OpenSSH's PAM use cannot be expected to be as good as other parts of the suite
          >
          > There is no chance that PAM will ever be fully integrated as near as I can tell, because there is no such thing as PAM working properly.

          IMHO OpenBSD doesn't needs PAM, but something LIKE PAM, oh yes it does.

          Comments

          1. By Miod Vallat (80.65.224.82) miod@ on

            > IMHO OpenBSD doesn't needs PAM, but something LIKE PAM, oh yes it does.
            >
            This is exactly what BSD auth is for. Ever had a look in /usr/libexec/auth on your system?

            Comments

            1. By Anonymous Coward (200.168.74.54) on

              > This is exactly what BSD auth is for. Ever had a look in /usr/libexec/auth on your system?

              They do do the same thing, I agree. But PAM has some fine grained controls that sometimes I miss in bsd auth, modularity and per-program control for example.

              Well so what makes nsswitch/ldap integration so hard?

              Comments

              1. By Anonymous Coward (66.11.66.41) on

                > > This is exactly what BSD auth is for. Ever had a look in /usr/libexec/auth on your system?
                >
                > They do do the same thing, I agree. But PAM has some fine grained controls that sometimes I miss in bsd auth, modularity and per-program control for example.
                >
                > Well so what makes nsswitch/ldap integration so hard?

                Nothing. Ldap authentication through bsd auth already works fine. And nsswitch has already been done, its just nobody commited it.

                Comments

                1. By Anonymous Coward (200.168.74.54) on

                  > Nothing. Ldap authentication through bsd auth already works fine. And nsswitch has already been done, its just nobody commited it.
                  >

                  I heard that there is a license issue around.

                  --
                  from login_ldap homepage:

                  login_ldap A bsd authentication module for authenticating users of an LDAP server is available here.

                  I've moved the older, vulnerable, versions of login_ldap as every now and again someone would download them instead of 3.4. Get 3.1 or 3.2. You can read the advisory for these versions here

                  It requires the OpenLDAP libraries (found in the openldap client port).
                  --

                  Are those OpenLDAP libraries licenses completely acceptable?
                  Well, maybe a port can be made to use login_ldap/OpenLDAP as the name service, but first the system needs to support it internally.

                  Comments

                  1. By Brad (209.5.161.190) brad at comstyle com on

                    > > Nothing. Ldap authentication through bsd auth already works fine. And nsswitch has already been done, its just nobody commited it.
                    > >
                    >
                    > I heard that there is a license issue around.
                    >
                    > --
                    > from login_ldap homepage:
                    >
                    > login_ldap A bsd authentication module for authenticating users of an LDAP server is available here.
                    >
                    > I've moved the older, vulnerable, versions of login_ldap as every now and again someone would download them instead of 3.4. Get 3.1 or 3.2. You can read the advisory for these versions here
                    >
                    > It requires the OpenLDAP libraries (found in the openldap client port).
                    > --
                    >
                    > Are those OpenLDAP libraries licenses completely acceptable?
                    > Well, maybe a port can be made to use login_ldap/OpenLDAP as the name service, but first the system needs to support it internally.

                    A much leaner LDAP client library is necessary.

                    Comments

                    1. By Anonymous Coward (213.196.240.74) on

                      [ nsswitch ]

                      > > > Nothing. Ldap authentication through bsd auth already works fine. And nsswitch has already been done, its just nobody commited it.

                      I sincerely hope nobody will, ever, add nsswitch
                      functionality because it just sucks major arse.

                      [ login_ldap ]

                      > A much leaner LDAP client library is necessary.

                      Felix von Leitner (fefe) provides TinyLDAP which
                      is read-only, so should be enough for login_ldap,
                      but my guess he'd be reluctant to relicence it
                      under BSD or similar licence... asking doesn't
                      hurt, though.

                      Comments

                      1. By Anonymous Coward (70.27.15.123) on

                        > I sincerely hope nobody will, ever, add nsswitch
                        > functionality because it just sucks major arse.

                        How does it "suck major arse"? What is so horrible about having users looked up remotely instead of only being able to have them in a text file? Is catching up to 25 year old tech really that bad?

                2. By Brad (209.5.161.190) brad at comstyle com on

                  > > > This is exactly what BSD auth is for. Ever had a look in /usr/libexec/auth on your system?
                  > >
                  > > They do do the same thing, I agree. But PAM has some fine grained controls that sometimes I miss in bsd auth, modularity and per-program control for example.
                  > >
                  > > Well so what makes nsswitch/ldap integration so hard?
                  >
                  > Nothing. Ldap authentication through bsd auth already works fine. And nsswitch has already been done, its just nobody commited it.
                  >

                  nsswitch cannot be used sine it relies on shared objects. This is the exact same reason PAM would never exist in OpenBSD, besides all the other issues too.

                  Comments

                  1. By Anonymous Coward (66.11.66.41) on

                    > nsswitch cannot be used sine it relies on shared objects. This is the exact same reason PAM would never exist in OpenBSD, besides all the other issues too.

                    What is wrong with relying on shared objects? Last I checked, there was a fair bit of stuff in /usr/lib.

                    Comments

                    1. By tedu (69.12.168.114) on

                      > > nsswitch cannot be used sine it relies on shared objects. This is the exact same reason PAM would never exist in OpenBSD, besides all the other issues too.
                      >
                      > What is wrong with relying on shared objects? Last I checked, there was a fair bit of stuff in /usr/lib.

                      static only architectures.

                      Comments

                      1. By Anonymous Coward (70.27.15.123) on

                        > > > nsswitch cannot be used sine it relies on shared objects. This is the exact same reason PAM would never exist in OpenBSD, besides all the other issues too.
                        > >
                        > > What is wrong with relying on shared objects? Last I checked, there was a fair bit of stuff in /usr/lib.
                        >
                        > static only architectures.

                        Yes, I realize openbsd likes to trade away useful functionality in favour of supporting obsolete crap. But is it really that big a deal to simply leave static only archs the way they are now, and only enable nsswitch on useful arch's? People using such archs are used to having to compile stuff statically themselves if they need it, like any apache modules, or modules for scripting languages, etc.

                        Comments

                        1. By tedu (71.139.182.193) on

                          > But is it really that big a deal to simply leave static only archs the way they are now, and only enable nsswitch on useful arch's?

                          yes.

                          Comments

                          1. By Anonymous Coward (66.11.66.41) on

                            > > But is it really that big a deal to simply leave static only archs the way they are now, and only enable nsswitch on useful arch's?
                            >
                            > yes.

                            #ifndef __SHITTY_ARCH__
                            nsswitch code goes here
                            #endif

                            is difficult?

                            Comments

                            1. By tedu (69.12.168.114) on

                              > > > But is it really that big a deal to simply leave static only archs the way they are now, and only enable nsswitch on useful arch's?
                              > >
                              > > yes.
                              >
                              > #ifndef __SHITTY_ARCH__
                              > nsswitch code goes here
                              > #endif
                              >
                              > is difficult?

                              i didn't say it was difficult. i said it was a big deal.

                              if you want an operating system which has different feature sets and where "supported" can mean anything from "runs fine" to "booted once" depending on the platform, i can make some recommendations for you. :)

                              one of the openbsd goals is that platforms should be consistent wherever possible. diffs which increase divergence are not so good.

                              nsswitch wouldn't work anyway without a completely dynamic root, or even trivial things like ls -l will do the wrong thing.

                              it's also possible to write a nsswitch like interface that uses a socket and doesn't depend on dynamic linking.

          2. By Han (213.84.147.9) han@mijncomputer.nl on

            Linux doesn't need PAM either. CRUX linux for instance comes without PAM for instance. Pretty decent Linux for a Linux, I'd say.

        2. By Anonymous Coward (203.58.120.11) on

          > PAM as a standard is broken, since none of the implementations work the same - it's because of this that there is not a PAM in OpenBSD, instead there is BSD auth. Since OpenBSD doesn't do PAM, OpenSSH's PAM use cannot be expected to be as good as other parts of the suite

          PAM isn't broken because there are multiple, (slightly) mutually incompatible implementations. It is broken because it assumes that all applications are written like 1970s-era /bin/login, performing no asynchronous actions.

    5. By Marc Balmer (209.5.161.190) mbalmer@openbsd.org on http://www.openbsd.org/

      > I wonder if any of the OpenBSD developers is dedicated to a BSD licensed LDAP implementation. As any other enterprise OS, I think OpenBSD deserves to have a built in external authentication and accounting system (read nsswitch/pam/etc). My request is not to adapt nss, pam, or any other GPL'd code, but to make similar ones under a more wide license (again, BSD).
      >
      > I have lost many opportunities to install OpenBSD because of this issue and had to stick with FreeBSD, Linux or even Solaris.

      There is actually work going on by me and others in the group. But it's a bit early to talk about this (we have a lean BER - and LDAP - implementation, it's an existing implementation which I completely cleaned up and stripped down to what we really need, but we have to fix a "typo" in the original license before we can actually use it... So be patient ;)

      Comments

      1. By Anonymous Coward (70.27.15.123) on

        > There is actually work going on by me and others in the group. But it's a bit early to talk about this (we have a lean BER - and LDAP - implementation, it's an existing implementation which I completely cleaned up and stripped down to what we really need, but we have to fix a "typo" in the original license before we can actually use it... So be patient ;)

        Its not an ldap implimentation that makes us not able to use openbsd. You can already use auth_ldap from ports for that. The problem is the lack of nsswitch or something to replace it. Without it, you have to sync passwd files all the time, which kinda makes centralized auth pointless.

        Comments

        1. By Anonymous Coward (209.5.161.190) on

          > > There is actually work going on by me and others in the group. But it's a bit early to talk about this (we have a lean BER - and LDAP - implementation, it's an existing implementation which I completely cleaned up and stripped down to what we really need, but we have to fix a "typo" in the original license before we can actually use it... So be patient ;)
          >
          > Its not an ldap implimentation that makes us not able to use openbsd. You can already use auth_ldap from ports for that. The problem is the lack of nsswitch or something to replace it. Without it, you have to sync passwd files all the time, which kinda makes centralized auth pointless.

          smartass. what do you think we need a lean implementation in the first place?

          Comments

          1. By Anonymous Coward (70.27.15.123) on

            > smartass. what do you think we need a lean implementation in the first place?

            Like I said, its not needed. An nsswitch implimentation is needed. Having to install openldap client libs from a pkg to use ldap is not a problem. Having no way to lookup user info in anything besides passwd file is a problem.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]