PAM modules

[Dag-Erling Smørgrav]

We currently have a number of PAM modules in ports, and while some of
them are specific to certain third-party software, many aren't. I
believe we would benefit from importing at least some of these into
base. My question is: which ones?

DES
--
Dag-Erling Smørgrav - d...@des.no
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/16/11 08:05, Dag-Erling Smørgrav wrote:
> We currently have a number of PAM modules in ports, and while some
> of them are specific to certain third-party software, many aren't.
> I believe we would benefit from importing at least some of these
> into base. My question is: which ones?

LDAP? (We do currently have some work on LDAP integration but not
sure if the community would be interested -- this would need an import
of stripped down OpenLDAP) and modifies OpenSSH to support public key
in LDAP directory.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOc4eUAAoJEATO+BI/yjfBUFgH/1+fWilKMu/4YJu0X2hUpDJI
EvOuG1Mx481eXAaTV+yfVaHwGs039EQIgJpk18CCC+UbCOV4kG0B0XpK5D3VdOPE
nHoXB38YiiyBe+LVYg3u1YPrjPAoULK2ih4qMOki6Wbtw8EqV344BNd0a70joY+z
JTnNsfJQcMKAO8RpppPxuf/yy6goRcQSMUmDCvxBiOS923vZu641kyBEzyFeC+GU
BJjLTXxcBQ5V9XNGgHmp7g4nwHPNwi0aOPs6Gudgj7u3hKKEkcY//Irdac+chopF
St4AJBCffsdl49TbQMYKUvTSIyUb5YeI8ixtFzwhhdGUZLEPDOvtOJNooCd1x/w=
=VRQC
-----END PGP SIGNATURE-----

[Mark Felder]

On Fri, 16 Sep 2011 12:29:56 -0500, Xin LI <del...@delphij.net> wrote:

> LDAP? (We do currently have some work on LDAP integration but not
> sure if the community would be interested -- this would need an import
> of stripped down OpenLDAP) and modifies OpenSSH to support public key
> in LDAP directory.

All of this would be greatly appreciated by myself and my fellow coworkers.

[Corey Smith]

On 09/16/2011 11:05 AM, Dag-Erling Smørgrav wrote:
> My question is: which ones?

security/pam_ssh_agent_auth

It is BSD licensed and handy for sudo.

-Corey Smith

[Robert Simmons]

2011/9/16 Dag-Erling Smørgrav <d...@des.no>:

> We currently have a number of PAM modules in ports, and while some of
> them are specific to certain third-party software, many aren't.  I
> believe we would benefit from importing at least some of these into

> base.  My question is: which ones?

Perhaps google authenticator?
http://code.google.com/p/google-authenticator/
http://www.freebsd.org/cgi/url.cgi?ports/security/pam_google_authenticator/pkg-descr

[David Cornejo]

2011/9/16 Dag-Erling Smørgrav <d...@des.no>

> We currently have a number of PAM modules in ports, and while some of
> them are specific to certain third-party software, many aren't. I
> believe we would benefit from importing at least some of these into
> base. My question is: which ones?
>

> DES
> --
> Dag-Erling Smørgrav - d...@des.no

> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-securi...@freebsd.org
> "
>

Another vote for LDAP

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/16/11 10:39, Mark Felder wrote:
> On Fri, 16 Sep 2011 12:29:56 -0500, Xin LI <del...@delphij.net> wrote:
>
>> LDAP? (We do currently have some work on LDAP integration but not
>> sure if the community would be interested -- this would need an import
>> of stripped down OpenLDAP) and modifies OpenSSH to support public key
>> in LDAP directory.
>
> All of this would be greatly appreciated by myself and my fellow coworkers.

I can publish the source code but note that it's for FreeBSD 8.2 and
OpenLDAP needs to be updated.

Changes are moderately intrusive but is in a manageable shape, it's used
in production at a company who wishes to remain anonymous (the work is
mostly putting together several open source models, fix bugs and they
have assigned a delegate for copyright to license it under compatible
license). I need to find some time to adapt the code to -HEAD and call
for feedback.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOc8WDAAoJEATO+BI/yjfB9p4IAIT82Z8I+6jkhyhCL/wbcXQk
KPAfpuPQCUjn1Lm2C/UUgWdBO17SYzBJUlyt1FJuDctGab18mJgvWMvjb+cUgXKH
lfcxUdmBxkhwwTSE7EfB4qLphn28si67INOZN3xSVzyXuxGTqwXcO5fJlbJly77B
nNS8JUu3X9tjMwGHwOWjG7R6n/bEdsmJUdWtMT2t3B6thFsStgqshTnKoBs18vPN
vWdY7vdX3Mco1kjLTGoq3DZUxZyBxn75IvSSpvFLtn4T4YT22U2V0KY5h1JUsz9q
MVQGLpUpudyFI8T+rzbQR3yxtv7gqgumlIuYpjF9rP0FtoQDcB2vRlMzAqM5j1o=
=m5hN
-----END PGP SIGNATURE-----

[Mike Carlson]

On 09/16/2011 08:05 AM, Dag-Erling Smørgrav wrote:
> We currently have a number of PAM modules in ports, and while some of
> them are specific to certain third-party software, many aren't. I
> believe we would benefit from importing at least some of these into
> base. My question is: which ones?
>
> DES

LDAP support out of the box would be fantastic.

Mike C

[Dan Lukes]

On 09/16/11 17:05, Dag-Erling Smørgrav:

> My question is: which ones?

An anti-brutal force module would be nice.

security/pam_af is my favorite. Configurable, fast, BSD license.

Dan

[Brandon Gooch]

On Sep 16, 2011 10:21 AM, "Dag-Erling Smørgrav" <d...@des.no> wrote:
>
> We currently have a number of PAM modules in ports, and while some of
> them are specific to certain third-party software, many aren't. I
> believe we would benefit from importing at least some of these into

> base. My question is: which ones?
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no

+1 for LDAP

-Brandon

[Jason Hellenthal]

On Sat, Sep 17, 2011 at 01:18:27AM -0400, Jason Hellenthal wrote:
>
> +1 for LDAP

Do not mean to reply to my own post but seems these offer the most IMHO
benefit to the project and end-users.

security/pam_jail A PAM module dropping users in jails after login
security/pam_krb5 A Pluggable Authentication Module for Kerberos5
security/pam_ldap A pam module for authenticating with LDAP
security/pam_mkhomedir Create HOME with a PAM module on demand
security/pam_p11 A PAM module using crypto tokens for auth authenticate against Unix PAM
security/pam_pwdfile A pam module for authenticating with flat passwd files
security/pam_require A PAM module for restricting access based on unix group or username
security/pam_smb NetBIOS domain logon PAM module
security/pam_ssh_agent_auth PAM module which permits authentication via ssh-agent
sysutils/pam_mount A PAM that can mount volumes for a user session

[Jason Hellenthal]

[Lev Serebryakov]

Hello, Xin.

You wrote 16 сентября 2011 г., 21:29:56:

> LDAP? (We do currently have some work on LDAP integration but not
> sure if the community would be interested -- this would need an import
> of stripped down OpenLDAP) and modifies OpenSSH to support public key
> in LDAP directory.

Minimal ldap client, nss/pam_ldap and SSH keys in LDAP out-of-box is
great!
But it is disagree with trend to stirp-down base system :(


--
// Black Lion AKA Lev Serebryakov <l...@FreeBSD.org>

[Lev Serebryakov]

Hello, Jason.

You wrote 17 сентября 2011 г., 9:24:34:

> security/pam_ldap A pam module for authenticating with LDAP

It needs nss_ldap too for reasonnabel work, and in such case
`net/nss-pam-ldapd' is better, as it two-in-one, may be with stripped
out cache daemon.

But all these ldap-related modules are strange in their desire to
have config files like "ldap.conf" :)

[Dag-Erling Smørgrav]

Jason Hellenthal <jh...@DataIX.net> writes:
> security/pam_jail A PAM module dropping users in jails after login
> security/pam_krb5 A Pluggable Authentication Module for Kerberos5

We already have that.

> security/pam_ldap A pam module for authenticating with LDAP

Not going to happen, since we don't have LDAP in base.

> security/pam_mkhomedir Create HOME with a PAM module on demand
> security/pam_p11 A PAM module using crypto tokens for auth authenticate against Unix PAM

Requires a PKCS11 implementation in base. I never finished the one I
started on...

> security/pam_pwdfile A pam module for authenticating with flat passwd files
> security/pam_require A PAM module for restricting access based on unix group or username

What does this do that pam_group doesn't?

> security/pam_smb NetBIOS domain logon PAM module

Apparently requires Perl to run, although this may be a bug in the port

> security/pam_ssh_agent_auth PAM module which permits authentication via ssh-agent
> sysutils/pam_mount A PAM that can mount volumes for a user session

That leaves us with the following candidates:

- pam_jail
- pam_mkhomedir
- pam_mount
- pam_pwdfile
- pam_ssh_agent_auth

and possibly also

- pam_require
- pam_smb

Note that pam_mkhomedir and pam_mount can be implemented using pam_exec
(possibly with some improvements) and scripts.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Łukasz Wąsikowski]

W dniu 20:59, Xin LI pisze:

>> We currently have a number of PAM modules in ports, and while some
>> of them are specific to certain third-party software, many aren't.
>> I believe we would benefit from importing at least some of these
>> into base. My question is: which ones?

> LDAP? (We do currently have some work on LDAP integration but not
> sure if the community would be interested -- this would need an import
> of stripped down OpenLDAP) and modifies OpenSSH to support public key
> in LDAP directory.

I'd love to see LDAP integration, I'm looking forward to it.

--
Best regards,
Lukasz Wasikowski

[Dag-Erling Smørgrav]

Xin LI <del...@delphij.net> writes:
> LDAP? (We do currently have some work on LDAP integration but not
> sure if the community would be interested -- this would need an import
> of stripped down OpenLDAP) and modifies OpenSSH to support public key
> in LDAP directory.

I would vote for importing a *complete* OpenLDAP, unless there are good
reasons not to; "slim base" isn't, considering how useful LDAP is.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Hartmann, O.]

On 09/18/11 20:03, Dag-Erling Smørgrav wrote:
> Xin LI <del...@delphij.net> writes:
>> LDAP? (We do currently have some work on LDAP integration but not
>> sure if the community would be interested -- this would need an import
>> of stripped down OpenLDAP) and modifies OpenSSH to support public key
>> in LDAP directory.
> I would vote for importing a *complete* OpenLDAP, unless there are good
> reasons not to; "slim base" isn't, considering how useful LDAP is.
>
> DES

If this is a real opportunity,

+1 for that.

[Mike Tancsa]

On 9/16/2011 3:10 PM, Corey Smith wrote:

> On 09/16/2011 11:05 AM, Dag-Erling Smørgrav wrote:
>> My question is: which ones?
>

> security/pam_ssh_agent_auth
>
> It is BSD licensed and handy for sudo.

Neato, I didnt know of this module for sudo! However, with the default
install on AMD64, I am getting coredump.

I added


# auth
auth include system
-
+auth sufficient /usr/local/lib/pam_ssh_agent_auth.so
file=/etc/sudokeys debug
# account
account include system

to /usr/local/etc/pam.d/sudo

and added

--- sudoers.sample 2011-09-19 13:24:56.000000000 -0400
+++ sudoers 2011-09-19 13:29:17.000000000 -0400
@@ -62,6 +62,10 @@
## Uncomment to enable special input methods. Care should be taken as
## this may allow users to subvert the command being run via sudo.
# Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE
QT_IM_SWITCHER"
+
+Defaults env_keep += SSH_AUTH_SOCK
+
+


I must be missing something obvious?

---Mike


--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/

[Patrick Lamaiziere]

Le Fri, 16 Sep 2011 15:10:09 -0400,
Corey Smith <cors...@gmail.com> a écrit :

Hello,

> > My question is: which ones?
>
> security/pam_ssh_agent_auth
>
> It is BSD licensed and handy for sudo.

But sudo itself is not the in base, so?

(while i'm here, +1 for ldap)

Regards.

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/18/11 11:03, Dag-Erling Smørgrav wrote:
> Xin LI <del...@delphij.net> writes:
>> LDAP? (We do currently have some work on LDAP integration but
>> not sure if the community would be interested -- this would need
>> an import of stripped down OpenLDAP) and modifies OpenSSH to
>> support public key in LDAP directory.
>
> I would vote for importing a *complete* OpenLDAP, unless there are
> good reasons not to; "slim base" isn't, considering how useful LDAP
> is.

The main concern I have is that users might want to stay on an older
FreeBSD release, while wanting features of a new OpenLDAP. That's why
I would prefer a libxml style import -- users always have choice to
install a new OpenLDAP without any concern of breaking their system
and we can always deliver security fixes with freebsd-update. Would
that make the trimmed down and renamed OpenLDAP import sound sensible?

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOeOpGAAoJEATO+BI/yjfBmX4H/0fx3Ld8+EkkbYX5LTXSyBt4
9x2ARzTi18+G/j+eYaiNutD4P+9voLnIGEiJwSTa5tXCtKkysRKZUkvetr+8uV7z
6aykrn+oaD0ol6nhWHESL4sCZh8nAoXLzQYaXKqw3FYH9pbQlckjr26UM4WGT8k/
Z129X0fh6TVN8vaztruJGNkLle69ruAgWpxMvTfligC8+Pbj7mV6YmdAwUidH3hL
YtlM7UoogZZzex3qpTUMq6gpKOA0BZTxPhOXWKhfgEz8enFuiYCo1Vs4DpS8S1i+
sbRcn6fTImRkC1FVDpPXEj/piwN/cIb/xv70gfeqgjxUL4LMFSrn9L5kkQ4K0wY=
=mRAO
-----END PGP SIGNATURE-----

[Dag-Erling Smørgrav]

Xin LI <del...@delphij.net> writes:
> The main concern I have is that users might want to stay on an older
> FreeBSD release, while wanting features of a new OpenLDAP. That's why
> I would prefer a libxml style import -- users always have choice to
> install a new OpenLDAP without any concern of breaking their system
> and we can always deliver security fixes with freebsd-update. Would
> that make the trimmed down and renamed OpenLDAP import sound sensible?

Yes, you have a point. So you're saying:

- client side only (for nss_ldap, pam_ldap etc)
- namespace hacks to avoid colliding with the port

right? I would definitely support that.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Lev Serebryakov]

Hello, Dag-Erling.

You wrote 21 сентября 2011 г., 1:19:11:

> Yes, you have a point. So you're saying:
> - client side only (for nss_ldap, pam_ldap etc)
> - namespace hacks to avoid colliding with the port
> right? I would definitely support that.

Maybe, BSD implementation, based on asn.1 to C compiler from Lev
Walkin (http://lionet.info/asn1c/blog/)? ;-)

Client-only part doesn't look very hard to implement, when all
boilerplate code (packing/unpacking/network processing, etc) is
auto-generated from RFCs.

--
// Black Lion AKA Lev Serebryakov <l...@FreeBSD.org>

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/20/11 15:25, Lev Serebryakov wrote:
> Hello, Dag-Erling. You wrote 21 сентября 2011 г., 1:19:11:
>
>> Yes, you have a point. So you're saying: - client side only (for
>> nss_ldap, pam_ldap etc) - namespace hacks to avoid colliding with
>> the port right? I would definitely support that.
> Maybe, BSD implementation, based on asn.1 to C compiler from Lev
> Walkin (http://lionet.info/asn1c/blog/)? ;-)
>
> Client-only part doesn't look very hard to implement, when all
> boilerplate code (packing/unpacking/network processing, etc) is
> auto-generated from RFCs.

That's true but is there any very compelling reason to do that (not
say no if someone really want to invest time on this and maintain it)
instead of just using an actively maintained codebase? The OpenLDAP
license is pretty similar to a BSD license:

===================================
The OpenLDAP Public License
Version 2.8, 17 August 2003

Redistribution and use of this software and associated documentation
("Software"), with or without modification, are permitted provided
that the following conditions are met:

1. Redistributions in source form must retain copyright statements
and notices,

2. Redistributions in binary form must reproduce applicable copyright
statements and notices, this list of conditions, and the following
disclaimer in the documentation and/or other materials provided
with the distribution, and

3. Redistributions must contain a verbatim copy of this document.

The OpenLDAP Foundation may revise this license from time to time.
Each revision is distinguished by a version number. You may use
this Software under terms of this license revision or under the
terms of any subsequent revision of the license.

THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND ITS
CONTRIBUTORS ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE OPENLDAP FOUNDATION, ITS CONTRIBUTORS, OR THE AUTHOR(S)
OR OWNER(S) OF THE SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

The names of the authors and copyright holders must not be used in
advertising or otherwise to promote the sale, use or other dealing
in this Software without specific, written prior permission. Title
to copyright in this Software shall at all times remain with copyright
holders.

OpenLDAP is a registered trademark of the OpenLDAP Foundation.

Copyright 1999-2003 The OpenLDAP Foundation, Redwood City,
California, USA. All Rights Reserved. Permission to copy and
distribute verbatim copies of this document is granted.
===================================

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOeRThAAoJEATO+BI/yjfBZc0H/1AftG4jvcAcA4vKVVDum6Bo
4tzA2sm1bK5ci/158ATF6VFvAEYQ3+rmRCDopkXvpbtJDzbuKOUEszI9SW2qfhz+
R0PIl64jYHngP3T6jw5theo+LJ/RHb/pIP7oIll1zANcpJIMHv9N00HY0HAFq4XQ
go3ASif1DU8OjHKWxH5zPLSBvGck6mBj+31J+0/FlohinEG3JJZBLQ+cAElTUV5r
fKhQ4rIlR1wwP7TrStapzdTHsyysAwblIOQ/WtzBhqxJcgh52TxI1QmJmILpmKQ7
vqFMpDnmOmgRZjfzSXfCSpd6ehx1Ko54KOm1m9WaFXI1zv8sTeP7AIoe1HO2fug=
=7ySY
-----END PGP SIGNATURE-----

[Lev Serebryakov]

Hello, Xin.

You wrote 21 сентября 2011 г., 2:34:09:

> That's true but is there any very compelling reason to do that (not
> say no if someone really want to invest time on this and maintain it)
> instead of just using an actively maintained codebase? The OpenLDAP
> license is pretty similar to a BSD license:

My point is not a license. I don't know, what is simpler:
(a) strip-down and rename API for OpenLDAP and later import new releases,
with new strip-downs and renames (IMHO, it is harder, than import and
support almost-intact code, like sendmail or bind),
or
(b) maintain local code, most of which is auto-generated from standard
by very mature and stable tool, as Lev's asn1c is. I know Lev
personally, and he says, that this tool is used by many Telco
operators and other Big Companies and he is not aware about any
outstanding bugs (from year 2007!) even when very complex (much more
complex than LDAPv3) ASN.1 rules are processed. Sometimes he is
contacted for support, but always it is not bugs in compiler, but some
other problems.

Maybe, import and maintaining of hacked OpenLDAP is simpler in
long-standing perspective. Maybe not. I only want to point, that if we
want our own LDAP client library, we don't need to write tons of
non-obvious, error-prone and security-sensitive code by hands.

--
// Black Lion AKA Lev Serebryakov <l...@FreeBSD.org>

[Kostik Belousov]

On Wed, Sep 21, 2011 at 02:43:47AM +0400, Lev Serebryakov wrote:
> Hello, Xin.
> You wrote 21 сентября 2011 г., 2:34:09:
>
> > That's true but is there any very compelling reason to do that (not
> > say no if someone really want to invest time on this and maintain it)
> > instead of just using an actively maintained codebase? The OpenLDAP
> > license is pretty similar to a BSD license:
> My point is not a license. I don't know, what is simpler:
> (a) strip-down and rename API for OpenLDAP and later import new releases,
> with new strip-downs and renames (IMHO, it is harder, than import and
> support almost-intact code, like sendmail or bind),
> or
> (b) maintain local code, most of which is auto-generated from standard
> by very mature and stable tool, as Lev's asn1c is. I know Lev
> personally, and he says, that this tool is used by many Telco
> operators and other Big Companies and he is not aware about any
> outstanding bugs (from year 2007!) even when very complex (much more
> complex than LDAPv3) ASN.1 rules are processed. Sometimes he is
> contacted for support, but always it is not bugs in compiler, but some
> other problems.
>
> Maybe, import and maintaining of hacked OpenLDAP is simpler in
> long-standing perspective. Maybe not. I only want to point, that if we
> want our own LDAP client library, we don't need to write tons of
> non-obvious, error-prone and security-sensitive code by hands.
>

Yes, the question of maintanence of the OpenLDAP code in the base
is not trivial by any means. I remember that openldap once broke
the ABI on its stable-like branch.

Having API renamed during the import for the actively-developed third-party
component is probably a stopper. I am aware of the rename done for ssh
import in ssh_namespace.h, but I do not think such approach scale.

Would the import of openldap and nss + pam ldap modules in src/ give any
benefits over having openldap and ldap nss + pam modules on the dvd1 ?

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/20/11 15:51, Kostik Belousov wrote:
[...]

> Yes, the question of maintanence of the OpenLDAP code in the base
> is not trivial by any means. I remember that openldap once broke
> the ABI on its stable-like branch.

That happen a few times however these are either not essential client
library (libldap and liblber) API or it's not changing parameters or
removing interfaces. Moreover, like the base libbsdxml.so, it's only
intended to be used by base system only so it's relatively easier to
maintain ABI stability, e.g. we can probably just expose only symbols
that we use, etc.

> Having API renamed during the import for the actively-developed
> third-party component is probably a stopper. I am aware of the
> rename done for ssh import in ssh_namespace.h, but I do not think
> such approach scale.

That's right. We did use a similar approach but again, if it's just
libldap and liblber, the change would be quite slow over years. We do
need to patch files.

> Would the import of openldap and nss + pam ldap modules in src/
> give any benefits over having openldap and ldap nss + pam modules
> on the dvd1 ?

Well, for ldap nss + pam models, people usually want them to "just
work" rather than wanting new features provided by a port installed
OpenLDAP. That's said, the user expects he can update any port
without risking into being locked out from the system plus these
modules can be upgraded or updated with existing binary update mechanisms.

The proposed approach would not be a whole OpenLDAP import (selected
client libraries only) nor would replace the port by the way.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOeS3vAAoJEATO+BI/yjfB7K4H/jumiosXs6OWZ02l5ntDb06k
MySle3NfvRBPIc0NL3FQUToJ2k1VzBJce53nAwXev/+YMOlbMjGcGlSuEzKSkQdE
j+Iwop+Od8/3sF4rIl7kBREMYzhZEiyT+Wf6LUxqVYqepso0PEoMlc5AoUZt1ghy
V1fdKrU7imhIM0IPgJJEi0LjK3z31CoujciuU8arnuBMbKNi5gZpJLRgB/L1s4jo
pSdNH95fCF487OsXu6sQZW0jdutaKxOsUiL1HFlwlFMzi8vCEFaG+TkwedmSeP7p
Ng4hTVTLM8JSmImVVTjF6qdQpZS8omVzt1MB4lE7gn/YwsUbLkSI+e8ejn1FP34=
=DQuu
-----END PGP SIGNATURE-----

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/20/11 14:19, Dag-Erling Smørgrav wrote:
> Xin LI <del...@delphij.net> writes:
>> The main concern I have is that users might want to stay on an
>> older FreeBSD release, while wanting features of a new OpenLDAP.
>> That's why I would prefer a libxml style import -- users always
>> have choice to install a new OpenLDAP without any concern of
>> breaking their system and we can always deliver security fixes
>> with freebsd-update. Would that make the trimmed down and
>> renamed OpenLDAP import sound sensible?
>

> Yes, you have a point. So you're saying:
>
> - client side only (for nss_ldap, pam_ldap etc) - namespace hacks
> to avoid colliding with the port
>
> right? I would definitely support that.

Yes exactly, the current version is just library to support these nss
and pam modules and have namespace hacks (so programs linking against
port OpenLDAP library will not see conflicts as well).

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOeTUGAAoJEATO+BI/yjfBRCAIAKQzG1dJhrLyKyYxJEH5qfXS
pm11L5cuQQto9yqm1TeMeT3qNMuNBo+bWt2QPJ0ef6qaOiL1oYIHdDyAkHqlDh1Z
q5zuwxZFzNAaBYF+QZLE0jSJpV05YpuN5bdkM5GilYw/xzbI4QmOstgJMyPS92WD
//oFfz9jHdQxJ0jZdp8dTDKMbgpOfUDfm/82zdDJPRnoK4dbJyn1xNFOB2H7KQyI
l246YN/W4/yR1wUDZlgjQ6zVoG4I6WvK1Lv7MU3YD2sNqfsnxoC+928U4Swd05Di
A1KXRWLsSB+2ZFnCXbGq3D22KhnmD4GQqxEZn5PZj0p2mDF3kjYDf3zlsUoofmw=
=DG1c

[Dag-Erling Smørgrav]

Kostik Belousov <kost...@gmail.com> writes:
> Yes, the question of maintanence of the OpenLDAP code in the base
> is not trivial by any means. I remember that openldap once broke
> the ABI on its stable-like branch.

That's irrelevant. Our own renamed subset of OpenLDAP would only be
used by our own code, primarily nss_ldap and pam_ldap, and would be
updated when and only when we decided that it needed updating, not every
time a new OpenLDAP release shipped. We did this successfully with
expat (libbsdxml), and there's no reason why it wouldn't work with
OpenLDAP.

> Having API renamed during the import for the actively-developed
> third-party component is probably a stopper. I am aware of the rename
> done for ssh import in ssh_namespace.h, but I do not think such
> approach scale.

The entire point of ssh_namespace.h is to minimize the amount of changes
required. Actually, when I say minimize, I mean "reduce to zero", and
the file itself is autogenerated, except for lining up the columns,
which I do manually. I don't know why you think it doesn't scale.

I don't think we have anything to gain by writing our own LDAP library.
Firstly, new code means new bugs, and this is security-critical code.
Secondly, any LDAP client library we wrote would have to have an API
that closely paralells OpenLDAP's; otherwise, we would also have to
rewrite nss_ldap and pam_ldap.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Kostik Belousov]

On Wed, Sep 21, 2011 at 11:29:49AM +0200, Dag-Erling Sm??rgrav wrote:
> Kostik Belousov <kost...@gmail.com> writes:
> > Yes, the question of maintanence of the OpenLDAP code in the base
> > is not trivial by any means. I remember that openldap once broke
> > the ABI on its stable-like branch.
>
> That's irrelevant. Our own renamed subset of OpenLDAP would only be
> used by our own code, primarily nss_ldap and pam_ldap, and would be
> updated when and only when we decided that it needed updating, not every
> time a new OpenLDAP release shipped. We did this successfully with
> expat (libbsdxml), and there's no reason why it wouldn't work with
> OpenLDAP.
>
> > Having API renamed during the import for the actively-developed
> > third-party component is probably a stopper. I am aware of the rename
> > done for ssh import in ssh_namespace.h, but I do not think such
> > approach scale.
>
> The entire point of ssh_namespace.h is to minimize the amount of changes
> required. Actually, when I say minimize, I mean "reduce to zero", and
> the file itself is autogenerated, except for lining up the columns,
> which I do manually. I don't know why you think it doesn't scale.
>
> I don't think we have anything to gain by writing our own LDAP library.
> Firstly, new code means new bugs, and this is security-critical code.
> Secondly, any LDAP client library we wrote would have to have an API
> that closely paralells OpenLDAP's; otherwise, we would also have to
> rewrite nss_ldap and pam_ldap.

I do not think that we would benefit from writing our own LDAP library
either. But I also doubt that importing ldap support in base would offer
any advantages in sum.

[Brooks Davis]

On Tue, Sep 20, 2011 at 05:21:03PM -0700, Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>

> On 09/20/11 15:51, Kostik Belousov wrote:
> [...]

> > Yes, the question of maintanence of the OpenLDAP code in the base
> > is not trivial by any means. I remember that openldap once broke
> > the ABI on its stable-like branch.
>

> That happen a few times however these are either not essential client
> library (libldap and liblber) API or it's not changing parameters or
> removing interfaces. Moreover, like the base libbsdxml.so, it's only
> intended to be used by base system only so it's relatively easier to
> maintain ABI stability, e.g. we can probably just expose only symbols
> that we use, etc.
>

> > Having API renamed during the import for the actively-developed
> > third-party component is probably a stopper. I am aware of the
> > rename done for ssh import in ssh_namespace.h, but I do not think
> > such approach scale.
>

> That's right. We did use a similar approach but again, if it's just
> libldap and liblber, the change would be quite slow over years. We do
> need to patch files.
>
> > Would the import of openldap and nss + pam ldap modules in src/
> > give any benefits over having openldap and ldap nss + pam modules
> > on the dvd1 ?
>
> Well, for ldap nss + pam models, people usually want them to "just
> work" rather than wanting new features provided by a port installed
> OpenLDAP. That's said, the user expects he can update any port
> without risking into being locked out from the system plus these
> modules can be upgraded or updated with existing binary update mechanisms.

This is certainly the largest benefit. I used a variant of pam_ldap for
authentication at $WORK for many years and the instability of the
OpenLDAP API was a constant headache.

That isn't to say that importing it into base is the only possible
solution. It is likely the most straightforward.

-- Brooks

[Jason Hellenthal]

Base package system that comes pre-installed ? or just ships with the
discs ?

> -- Brooks

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Well first and most important, someone will need to implement that,
but to be more specific there are a lot of issues that needs to be
solved like:

- How to update your system? LPK patchset for instance needs to be a
part of OpenSSH (not a loadable module) so we end up with a modified
sshd binary. "make installworld" need to know and don't patch it;
- How to patch your system? A mechanism like freebsd-update needs to
be implemented for these essential security services;
- How to update these "base packages"? There need to be a way that
is no harder than 'make installworld' in my opinion.

That's said, all these are not impossible without direct base system
integration, but integration is the most straightforward way at this
moment.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOeiCgAAoJEATO+BI/yjfB0gUH/2Sv52kW8GEACIisgkA+qfcS
eVjViqR5f4JE8JmSEnblHX5RWw96MEi9rsdgHiHFAmBed4CxG/SLr4Xjc5Ozv9EV
0zwThyAan5V0AuJjvAd9/pO/FkilzlQG4N2+wrzjB46FdH8YpBLcV57eSKUVpHO1
SA2t27qTC5Mo6ysQUutwQV00ujEtXL1KtsXl6iJLPKuKe9wdeJNBXQ3lkeCOsG/H
nBCPsAbb17H+RseSePCXTox4za5hLHCD2wsaqtydD08WO1bUf4hhYkQoy0IZ+q4z
DteS4qtDYzpoP5sbX/iY5vkXGHglOWpZzWcsfuHR5ZgIaXeEuk47UDHf0H632BE=
=BuI/
-----END PGP SIGNATURE-----

[Gleb Kurtsou]

On (20/09/2011 17:51), Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>

> On 09/20/11 14:19, Dag-Erling Smørgrav wrote:
> > Xin LI <del...@delphij.net> writes:
> >> The main concern I have is that users might want to stay on an
> >> older FreeBSD release, while wanting features of a new OpenLDAP.
> >> That's why I would prefer a libxml style import -- users always
> >> have choice to install a new OpenLDAP without any concern of
> >> breaking their system and we can always deliver security fixes
> >> with freebsd-update. Would that make the trimmed down and
> >> renamed OpenLDAP import sound sensible?
> >
> > Yes, you have a point. So you're saying:
> >
> > - client side only (for nss_ldap, pam_ldap etc) - namespace hacks
> > to avoid colliding with the port
> >
> > right? I would definitely support that.
>
> Yes exactly, the current version is just library to support these nss
> and pam modules and have namespace hacks (so programs linking against
> port OpenLDAP library will not see conflicts as well).

It wasn't explicitly mentioned, but instead of adding ssh-namespace.h
like hacks we could add local symbol versions to ldap shared libraries.
That would make impact on OpenLDAP from ports and its users minimal.
Binary could be linked against both OpenLDAP and ldap from base in case
when libbsdldap.so is indirect dependency used by another library from
base. That is not the case with libbsdxml.so

Thanks,
Gleb.

>
> Cheers,
> - --
> Xin LI <del...@delphij.net> https://www.delphij.net/
> FreeBSD - The Power to Serve! Live free or die
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (FreeBSD)
>

> iQEcBAEBCAAGBQJOeTUGAAoJEATO+BI/yjfBRCAIAKQzG1dJhrLyKyYxJEH5qfXS
> pm11L5cuQQto9yqm1TeMeT3qNMuNBo+bWt2QPJ0ef6qaOiL1oYIHdDyAkHqlDh1Z
> q5zuwxZFzNAaBYF+QZLE0jSJpV05YpuN5bdkM5GilYw/xzbI4QmOstgJMyPS92WD
> //oFfz9jHdQxJ0jZdp8dTDKMbgpOfUDfm/82zdDJPRnoK4dbJyn1xNFOB2H7KQyI
> l246YN/W4/yR1wUDZlgjQ6zVoG4I6WvK1Lv7MU3YD2sNqfsnxoC+928U4Swd05Di
> A1KXRWLsSB+2ZFnCXbGq3D22KhnmD4GQqxEZn5PZj0p2mDF3kjYDf3zlsUoofmw=
> =DG1c

[Doug Barton]

On 09/16/2011 08:05, Dag-Erling Smørgrav wrote:
> We currently have a number of PAM modules in ports, and while some of
> them are specific to certain third-party software, many aren't. I
> believe we would benefit from importing at least some of these into

> base. My question is: which ones?

For the sake of having the opposing viewpoint represented, I'm opposed
to importing more of this stuff into the base. Given that it works just
fine as it is, the benefits of importing it would have to overwhelmingly
compensate for the negatives of having to keep them up to date in the base.

Taking ldap as an example, the subset of our users who need this
functionality are already able to get it from the ports tree, where it
is easier to keep up to date across multiple FreeBSD versions.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

[Benjamin Kaduk]

On Tue, 20 Sep 2011, Xin LI wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>

> On 09/20/11 15:51, Kostik Belousov wrote:
> [...]
>> Yes, the question of maintanence of the OpenLDAP code in the base
>> is not trivial by any means. I remember that openldap once broke
>> the ABI on its stable-like branch.
>
> That happen a few times however these are either not essential client
> library (libldap and liblber) API or it's not changing parameters or
> removing interfaces. Moreover, like the base libbsdxml.so, it's only
> intended to be used by base system only so it's relatively easier to
> maintain ABI stability, e.g. we can probably just expose only symbols
> that we use, etc.

This is not without its own failures. For example, I sometimes find
myself wanting a kgetcred(1) from heimdal, but we do not build it as part
of our base heimdal. As a separate utility, this is not so bad; for a
library, things can get much more annoying.
Only exposing a limited set of symbols can make third-party tools that
want extra symbols very sad, unless it is easy to drop in a full version
from ports and still have all of base "just work". I do not quite think
that the current state of ports for ldap would "just work" without some
extra configuration (though, nor have I tried something like it).

-Ben Kaduk

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/22/11 19:19, Benjamin Kaduk wrote:
> On Tue, 20 Sep 2011, Xin LI wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> On 09/20/11 15:51, Kostik Belousov wrote: [...]
>>> Yes, the question of maintanence of the OpenLDAP code in the
>>> base is not trivial by any means. I remember that openldap once
>>> broke the ABI on its stable-like branch.
>>
>> That happen a few times however these are either not essential
>> client library (libldap and liblber) API or it's not changing
>> parameters or removing interfaces. Moreover, like the base
>> libbsdxml.so, it's only intended to be used by base system only
>> so it's relatively easier to maintain ABI stability, e.g. we can
>> probably just expose only symbols that we use, etc.
>
> This is not without its own failures. For example, I sometimes
> find myself wanting a kgetcred(1) from heimdal, but we do not build
> it as part of our base heimdal. As a separate utility, this is not
> so bad; for a library, things can get much more annoying. Only
> exposing a limited set of symbols can make third-party tools that
> want extra symbols very sad, unless it is easy to drop in a full
> version from ports and still have all of base "just work". I do
> not quite think that the current state of ports for ldap would
> "just work" without some extra configuration (though, nor have I
> tried something like it).

Third party utilities should use symbols provided by port OpenLDAP
library because base system symbols are namespaced and third party
application have no chance to reference them (e.g. no header
installed, etc) unless they are part of base system and be built with it.

Cheers,
- --
Xin LI <del...@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOfFpHAAoJEATO+BI/yjfBjxwH/iKLFZkvzkowW50FyuxnesmQ
r4f9bvOLAH8iRva8GJEJDJaTqQHKWVJ8yIkT49WC8VgoNAcpkvzkOXm2Xe658yuz
Ca5TNIFvJccw6MtH6nicE4REy+YEOwcnSQTLHqcPBKiSLH3RFrklOZ3YjGrR8qgX
9WmVI6rZ9CbHwUVsWyJUOUYrCsAPsLpraqyfhwM1/ZXnr3mGNKayb8KMjgmy0gGI
V2J9bIjPd2E6vDLl8vYJxQZ+pPrUcuPJ06v+SFN9vmbC7UadRWZr37DsX1Kba4pN
3qRKemze61qMPi39Xd8Wt7Og6+GAIKnMV2cX2+a+3gExO0haMl4E/V9BU6UpVUA=
=t3Ti
-----END PGP SIGNATURE-----