[Fusionforge-general] PHP Hacks: Offsets to avoid company UID's/GID's

Roland Mas lolando at debian.org
Wed Aug 12 10:24:54 CEST 2009


Curt Mills, 2009-08-11 14:31:07 -0700 :
[...]

> I've been using the "UNIX" plugin for several years.  What is the
> purpose of having FForge write to /etc/passwd, shadow, and group using
> it?  Is that data needed only for CVS (which we're not using) and
> shell access?  Can I disable those writes and keep everything private
> in Postgres pertaining to UID's/GID's for users/projects?

I think it should be fine, at least for the user accounts.  The groups
may be required, since the projects' websites are stored in directories
owned by the groups, but you can probably disable that.

> If so, that's what I'd like to do plus have FForge get new user
> UID's/GID's from LDAP and load it into Postgres.  Users already have
> shell access using their company accounts on this server.

  Great :-)

>> There's even a check to disallow the creation of a FusionForge
>> account if a local account of the same name already exists.
>
> Which is not exactly what I'm after:  Our I.T. department creates
> user accounts, not me or FForge.  I'd like FForge to use
> I.T.-created LDAP/AD accounts for all new FForge users, maybe
> keeping project ID's in Postgres only?  That way we could use the
> company logins for FForge and FForge-created project ID's could
> conflict with ID's used in the company and it wouldn't matter (or
> would it?).  I could then dispense with the custom PHP tweaks so the
> next FusionForge upgrade would be less painful.

  Yes.  If you disable Unix account/group creation, the FusionForge
accounts will only exist in FusionForge.

> We use Kerberos for authentication, and LDAP or AD for authorization
> if that makes sense.  I'm not up on that sort of thing: Kerberos and
> PAM are black boxes to me, not to mention LDAP and AD.  Our I.T.
> dept. takes care of that so I don't have to.

  I once participated in a job where we had to get GForge (at that time)
to use Kerberos for transparent authentication (SSO).  The details are a
bit fuzzy, but I think we used ldapextauth as a starting point, plus
some configuration in Apache.

>> As an aside: if you use LDAP, you can plug FusionForge onto it so
>> LDAP accounts (and their passwords) are automatically usable inside
>> FusionForge.  Look for the "ldapextauth" plugin.
>
> I messed with "ldapextauth" 2.5 years ago with GForge 4.5.x and
> couldn't get it to work, perhaps because of our use of kerberos for
> authentication instead of ldap.  Like I said I'm not well-versed on
> that stuff.  Add to that I'm not sure what plugins do read-only access
> and which are read/write...  I'm not allowed to do writes to LDAP or
> AD.

  Ldapextauth only does reads on the LDAP server.

[...]

> The CentOS 5.3 server itself is set up to use kerberos/PAM/LDAP.
> Users can log in with their company accounts for shell access.  Can I
> use the already-configured PAM setup for FusionForge authentication?

  Not currently.  That would mean developing a "pamextauth"
authentication plugin or so.

> Perhaps the "NSSPGSQL" plugin would give us that?

  Not really, it's the other way round.  The historical data flow is
that the forge's database is the canonical source for accounts, and
these accounts then get promoted to shell accounts via one of several
methods (classic Unix passwd/shadow, LDAP, or NSS-PGSQL).  To accomodate
enterprise setups, there's the *extauth mechanism (only ldapextauth so
far, but more could be developed if needed), which injects the user
accounts from the corporate LDAP server into the forge's database on the
fly when the user connects to the forge's web interface.

> If I'm not using CVS but only SVN over DAV, can I get rid of the
> writes to /etc/passwd, shadow, and group altogether?

  Yes, modulo the groups directories.

> Hopefully all of the above makes sense.  I've done a lot of reading
> of the forums, docs, and PHP code, as well as looking around in the
> database, yet still haven't figured out whether FusionForge can be
> interleaved with our existing authentication system.

  It probably can, but that may require a (moderate) amount of work.

Roland.
-- 
Roland Mas

Je suis un anti-virus de signature.
Copiez-moi dans la vôtre pour éliminer les virus de signature !




More information about the Fusionforge-general mailing list