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

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

It is BSD licensed and handy for sudo.

On 09/16/11 10:39, Mark Felder wrote:

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 <delp...@delphij.net>   https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

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

Dan

+1 for LDAP

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

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

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

 - 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.

On 09/17/2011 05:30 AM, Hartmann, O. wrote:

On (09/17/11 14:30), Hartmann, O. wrote:

I think an interesting concept would be something that gave us the
ability to (easily) tie certain ports into software from the base system.
Something that would allow the software to be more easily kept current.
Perhaps this could be done via some sort of base-integrated ports
category that require extra-special care/controls when being updated.

Using the above idea, perhaps we could have ISOs or the like available
that include these 'base-integrated' ports pre-installed, thus giving
users the ability to (effectively) have an out-of-the-box solution that
included LDAP support, etc., while still having these 'base-integrated'
ports loosely coupled with the base OS.  The concept could keep the base
system lean, but provide the flexibility that users desire.

Obviously there are some complexities associated with implementing the
framework and details that would need to be worked out, but this could
address:
-The desire to keep the base system lean
-The desire to provide certain features out-of-the-box
-The ability to keep these 'base-integrated' ports more current in terms
of features/functionality

-r

On 09/17/11 06:53, Ryan Steinmetz wrote:
[...]

        http://people.freebsd.org/~delphij/misc/freebsd8.2-ldap.diff.xz

For interested parties.

That work was done to meet quakelee@'s company's needs (mostly done by
him, I helped him with some minor things with my weekends) and the
patch might needs some cleanup work (I've stripped down the unrelated
part like bringing rsync, sudo to their base system but it's well
possible rthat I've missed something or haven't removed some junk in
this patchset -- ask me and/or quakelee@ if that's the case, their
patched system works fine and I have everything in our git so let me
know if that works).

Speaking for having or not this by default for FreeBSD: It's not hard
for us to make a customized distribution, and the patchset allows one
to build a LDAP-free system, we have stripped down OpenLDAP to only do
client side and the symbols have been renamed to avoid conflicts with
port OpenLDAP.  Personally I don't consider an Operating System that
have no built-in LDAP support as a complete one and consider this:
what happens when OpenLDAP's shared library version bumped (this is
not rare) and your LDAP-linked sshd, pam models would do?

"base-integrated" port -- I wouldn't object if that would ever happen
but I bet it's a much bigger one than LDAP integration :)  It may take
me a day or two days to get our patchset cleaned up and updated to
- -HEAD and latest OpenLDAP -stable and universe it, plus test on amd64,
but implementing a shiny new framework is not something we (I and
quakelee@) could do.

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

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

Hello,

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

Running with -D9, normally it looks something like

% sudo -D9 su
sudo: settings: debug_level=9
sudo: settings: progname=sudo
sudo: settings: network_addrs=....
sudo: sudo_mode 1
sudo: policy plugin returns 1
sudo: command info: umask=022
sudo: command info: command=/usr/bin/su
sudo: command info: runas_uid=0
sudo: command info: runas_gid=0
sudo: command info: runas_groups=0,5
sudo: command info: closefrom=3
sudo: command info: set_utmp=true
sudo: command info: login_class=default

where as on amd64,

% sudo -D9 su
sudo: settings: debug_level=9
sudo: settings: progname=sudo
sudo: settings: network_addrs=....
sudo: sudo_mode 1
Segmentation fault

It seems to die in the call to

static int
policy_check(struct plugin_container *plugin, int argc, char * const argv[],
    char *env_add[], char **command_info[], char **argv_out[],
    char **user_env_out[])
{
    return plugin->u.policy->check_policy(argc, argv, env_add, command_info,
        argv_out, user_env_out);

        ---Mike