[gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Diego "Flameeyes" Pettenò]

[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]

Ok, second part of my odyssey in PAM implementations.
After a day searching for example config files and so on, I found out that 
Linux-PAM already support the include syntax of openpam since version 0.78.
This is useful to our needs, because it allow us to have a single 
configuration file which works on both openpam and linux-pam.

The old syntax is that:

class required pam_stack.so service=system-auth

the new one should be:

class include system-auth

Now, to start making the changes needed to have complete openpam/linuxpam 
intercompatibility, there's need of a few changes in tree:
- we need a virtual/pam, which could be provided by linux-pam or by openpam;
- we need an ebuild for openpam (i've wrote one, but still misses a few 
points, mainly for the missing thigns here stated)
- we need a virtual/pam-modules which could be provided by linux-pam or by a 
new freebsd-pam-modules (they work also under linux as far as I know... i'll 
test that better when I'll have the other things working, now is a bit 
complicated to do), openpam will pdepend on freebsd-pam-modules to provide 
both in a simple way.
- not needed, but surely helpful, sys-libs/pam could be renamed to 
sys-libs/linux-pam, or sys-libs/Linux-PAM which is it's exact spelling. This 
way we have a consistent naming scheme
- all the dependency on sys-libs/pam should be changed to virtual/pam (also if 
they use pam_stack.so under openpam, until we have fixed everything this 
could be worked around by the ones using openpam... initially only 
experimental users should use it, so they should be able to cope with broken 
configuration files, see next point for solution)
- the new ebuilds should add a new configuration file with the new syntax, and 
should depend on: || ( >=sys-libs/pam-0.78 virtual/pam ). This would fix the 
previous point, as who is using openpam will use the ~arch packages which 
will be fixed one by one (by me, submitting patches to maintainers), this way 
the packages will work out-of-the-box for both g/linux and g/fbsd users (i 
haven't searched on macosx, but should be, as they have the same userlands of 
fbsd).

I'll work anyway on a pam_stack hack for openpam, also if I'm not sure if, 
when and how I'll be able to make it work... also I don't like too much 
messing with security stuff :/

Well.. if there's someone (lu_zero? :) ) which doesn't like this solution... 
comments accepted :)

-- 
Diego "Flameeyes" Pettenò
http://wwwstud.dsi.unive.it/~dpetteno/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Luca Barbato]

Diego "Flameeyes" Pettenò wrote:
> 
> I'll work anyway on a pam_stack hack for openpam, also if I'm not sure if, 
> when and how I'll be able to make it work... also I don't like too much 
> messing with security stuff :/
> 
> Well.. if there's someone (lu_zero? :) ) which doesn't like this solution... 
> comments accepted :)
> 
I like the plan.

lu

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Manager
http://dev.gentoo.org/~lu_zero


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Gregorio Guidi]

On Wednesday 30 March 2005 22:15, Diego "Flameeyes" Pettenò wrote:
> Ok, second part of my odyssey in PAM implementations.
> After a day searching for example config files and so on, I found out that
> Linux-PAM already support the include syntax of openpam since version 0.78.
> This is useful to our needs, because it allow us to have a single
> configuration file which works on both openpam and linux-pam.
> ...

You may be interested in this bug:
http://bugs.gentoo.org/show_bug.cgi?id=77093

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Fabian Zeindl]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

Are there anywhere more informations about OpenPAM? Because I read
several threads about problems with Udev and PAM's console.perms. There
are a few threads which suggest deinstalling PAM under Gentoo.

Is console.perms still used within openPAM?

greetings
fabian

Gregorio Guidi wrote:
> On Wednesday 30 March 2005 22:15, Diego "Flameeyes" Pettenò wrote:
>
>>Ok, second part of my odyssey in PAM implementations.
>>After a day searching for example config files and so on, I found out that
>>Linux-PAM already support the include syntax of openpam since version 0.78.
>>This is useful to our needs, because it allow us to have a single
>>configuration file which works on both openpam and linux-pam.
>>...
>
>
> You may be interested in this bug:
> http://bugs.gentoo.org/show_bug.cgi?id=77093
>
> --
> gentoo-dev@gentoo.org mailing list
>
>


--
Musik ist niemals illegal: www.fairsharing.de

I prefer signed/encrypted Mail:
Fingerprint: CFE8 38A7 0BC4 3CB0 E454  FA8D 04F9 B3B6 E02D 25BA

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Diego "Flameeyes" Pettenò]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Thursday 31 March 2005 16:10, Fabian Zeindl wrote:
> Are there anywhere more informations about OpenPAM? Because I read
> several threads about problems with Udev and PAM's console.perms. There
> are a few threads which suggest deinstalling PAM under Gentoo.
See my email of just a minute ago about pam_console.
console.perms is something related with pam_console which, as I said, is only 
a workaround which does more bad than good things atm.

I'd like to see it off-the-tree, but as this is not practical, moving it out 
of sys-libs/pam ebuild could be enough to have it safe for now.

Please note that is not enabled by default on recent systems.


About removing PAM, it's not practical in a recent linux system, but maybe 
when openpam will be enough well integrated on gentoo it could be a good 
alternative as it's way lighter and minimalist.

-- 
Diego "Flameeyes" Pettenò
http://wwwstud.dsi.unive.it/~dpetteno/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 3732 bytes --]

On Wed, 2005-03-30 at 22:15 +0200, Diego "Flameeyes" Pettenò wrote:
> Ok, second part of my odyssey in PAM implementations.
> After a day searching for example config files and so on, I found out that 
> Linux-PAM already support the include syntax of openpam since version 0.78.
> This is useful to our needs, because it allow us to have a single 
> configuration file which works on both openpam and linux-pam.
> 
> The old syntax is that:
> 
> class required pam_stack.so service=system-auth
> 
> the new one should be:
> 
> class include system-auth
> 

Right, like I said this is the better idea in previous post (replied
before reading this one).

> Now, to start making the changes needed to have complete openpam/linuxpam 
> intercompatibility, there's need of a few changes in tree:
> - we need a virtual/pam, which could be provided by linux-pam or by openpam;

Right.  It should be profile specific I guess, as I am not sure we want
it on linux boxes to keep things simple.

> - we need an ebuild for openpam (i've wrote one, but still misses a few 
> points, mainly for the missing thigns here stated)

And you/bsd_peeps will obviously maintain it.

> - we need a virtual/pam-modules which could be provided by linux-pam or by a 
> new freebsd-pam-modules (they work also under linux as far as I know... i'll 
> test that better when I'll have the other things working, now is a bit 
> complicated to do), openpam will pdepend on freebsd-pam-modules to provide 
> both in a simple way.

Why?  What good will they do on linux?  Just stick them in bsd profile.

> - not needed, but surely helpful, sys-libs/pam could be renamed to 
> sys-libs/linux-pam, or sys-libs/Linux-PAM which is it's exact spelling. This 
> way we have a consistent naming scheme

Like I said before, only real reason why I will biatch about this one,
is its called 'pam' on all linux distro's, and it will be another lost
history (ok, so the workaround is a schlepp) case without real cause.

> - all the dependency on sys-libs/pam should be changed to virtual/pam (also if 
> they use pam_stack.so under openpam, until we have fixed everything this 
> could be worked around by the ones using openpam... initially only 
> experimental users should use it, so they should be able to cope with broken 
> configuration files, see next point for solution)

Well, the first thing will be more testing to get Linux-PAM-0.78 stable,
and then go through the tree - think that will be more the deciding
factor than bsd (who cares about bsd anyhow :P).

> - the new ebuilds should add a new configuration file with the new syntax, and 
> should depend on: || ( >=sys-libs/pam-0.78 virtual/pam ). This would fix the 
> previous point, as who is using openpam will use the ~arch packages which 
> will be fixed one by one (by me, submitting patches to maintainers), this way 
> the packages will work out-of-the-box for both g/linux and g/fbsd users (i 
> haven't searched on macosx, but should be, as they have the same userlands of 
> fbsd).
> 

Ugh, no - just more crud that somebody will have to clean out later.
Like I said, get pam-0.78 and issues fixed, bumped to stable on all
linux archs, and we can scourge the tree.

> I'll work anyway on a pam_stack hack for openpam, also if I'm not sure if, 
> when and how I'll be able to make it work... also I don't like too much 
> messing with security stuff :/
> 

Sorry, you are on your own here.

> Well.. if there's someone (lu_zero? :) ) which doesn't like this solution... 
> comments accepted :)
> 


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Diego "Flameeyes" Pettenò]

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

On Wednesday 06 April 2005 23:38, Martin Schlemmer wrote:
> > - we need an ebuild for openpam (i've wrote one, but still misses a few
> > points, mainly for the missing thigns here stated)
> And you/bsd_peeps will obviously maintain it.
Sure, as I said I'm taking care of it and I'll do for all the time I can.

> > openpam will pdepend on
> > freebsd-pam-modules to provide both in a simple way.
> Why?  What good will they do on linux?  Just stick them in bsd profile.
Mainly, openpam is shipped without any kind of module. If someone would like 
to replace Linux-PAM with openpam on a Linux system (it's possible), I'd much 
prefer to provide it with everything he needs. Linux-PAM builds its own 
modules, openpam just provide pam implementation and needs other packages to 
provide the basic modules. FreeBSD's modules should work on Linux and this 
would make possible the switch between Linux-PAM and openpam.

> Like I said before, only real reason why I will biatch about this one,
> is its called 'pam' on all linux distro's, and it will be another lost
> history (ok, so the workaround is a schlepp) case without real cause.
Actually it's called libpam usually :)
Mainly, calling it pam is usual on linux-centric systems, but as Gentoo is not 
only Linux, and "it's all about choice", having it called as it's named, 
IMHO, is a way to state clearly what it is.
Just take a look to telnet-bsd and netkit-telnetd. On Debian there's 
netkit-telnet which is called just telnet.
Anyway this is only "cosmetic" and for what I "need" or better I feel is 
needed, this is something which can be omissed.

> Ugh, no - just more crud that somebody will have to clean out later.
> Like I said, get pam-0.78 and issues fixed, bumped to stable on all
> linux archs, and we can scourge the tree.
That's a decision up to you as pam mantainers :)
Anyway I'm available to add the temporary fixes, trace them, and remove them 
when all is done, if needed.

> > I'll work anyway on a pam_stack hack for openpam, also if I'm not sure
> > if, when and how I'll be able to make it work... also I don't like too
> > much messing with security stuff :/
> Sorry, you are on your own here.
I know and I'll try to do everything I can, but if in the mean time it could 
be used the other method should be enough until there's a way to "support" 
pam_stack on openpam.

-- 
Diego "Flameeyes" Pettenò
http://wwwstud.dsi.unive.it/~dpetteno/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2852 bytes --]

On Thu, 2005-04-07 at 00:11 +0200, Diego "Flameeyes" Pettenò wrote:

> > > openpam will pdepend on
> > > freebsd-pam-modules to provide both in a simple way.
> > Why?  What good will they do on linux?  Just stick them in bsd profile.
> Mainly, openpam is shipped without any kind of module. If someone would like 
> to replace Linux-PAM with openpam on a Linux system (it's possible), I'd much 
> prefer to provide it with everything he needs. Linux-PAM builds its own 
> modules, openpam just provide pam implementation and needs other packages to 
> provide the basic modules. FreeBSD's modules should work on Linux and this 
> would make possible the switch between Linux-PAM and openpam.
> 

I was more talking about the virtual/pam-modules (or whatever).  Having
a a PDEPEND is just fine.

> > Like I said before, only real reason why I will biatch about this one,
> > is its called 'pam' on all linux distro's, and it will be another lost
> > history (ok, so the workaround is a schlepp) case without real cause.
> Actually it's called libpam usually :)
> Mainly, calling it pam is usual on linux-centric systems, but as Gentoo is not 
> only Linux, and "it's all about choice", having it called as it's named, 
> IMHO, is a way to state clearly what it is.
> Just take a look to telnet-bsd and netkit-telnetd. On Debian there's 
> netkit-telnet which is called just telnet.
> Anyway this is only "cosmetic" and for what I "need" or better I feel is 
> needed, this is something which can be omissed.
> 

Like I said - its more just me than anything else.

> > Ugh, no - just more crud that somebody will have to clean out later.
> > Like I said, get pam-0.78 and issues fixed, bumped to stable on all
> > linux archs, and we can scourge the tree.
> That's a decision up to you as pam mantainers :)
> Anyway I'm available to add the temporary fixes, trace them, and remove them 
> when all is done, if needed.
> 

Id rather just do it cleanly.

> > > I'll work anyway on a pam_stack hack for openpam, also if I'm not sure
> > > if, when and how I'll be able to make it work... also I don't like too
> > > much messing with security stuff :/
> > Sorry, you are on your own here.
> I know and I'll try to do everything I can, but if in the mean time it could 
> be used the other method should be enough until there's a way to "support" 
> pam_stack on openpam.
> 

Well, the include should work, be the cleanest and less up and down way
(you really do not want to coordinate a big change across the tree in
more than one direction more than once - you usually end up burning
yourself) - I'll work through the pam bugs for 0.78, and see if we can
get it pushed to stable.


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Diego "Flameeyes" Pettenò]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

On Thursday 07 April 2005 01:17, Martin Schlemmer wrote:
> I was more talking about the virtual/pam-modules (or whatever).  Having
> a a PDEPEND is just fine.
I was thinking of the virtual for future expansion on NetBSD and other, but 
this is probably better done using an || PDEPEND when it will be needed.

> > That's a decision up to you as pam mantainers :)
> > Anyway I'm available to add the temporary fixes, trace them, and remove
> > them when all is done, if needed.
> Id rather just do it cleanly.
Another solution which could be done "quickly" could be that:
- add dependency for the packages which uses include on virtual/pam
- provide virtual/pam with pam version 0.78 (and openpam, in my and/or fbsd 
overlay until it's mature enough to be merged)

In this way the dependency could be expressed in a single way which won't need 
to be fixed in future.

-- 
Diego "Flameeyes" Pettenò
http://wwwstud.dsi.unive.it/~dpetteno/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] portage on NetBSD (was: Pluggable Hell Part 2: Fixing everything up!)

[Stefan Sperling]

On Fri, Apr 08, 2005 at 09:22:33AM +0200, Diego Flameeyes Pettenò wrote:
> I was thinking of the virtual for future expansion on NetBSD and other, but 
> this is probably better done using an || PDEPEND when it will be needed.

That's interesting.
Is anybody planning or working on a NetBSD port of portage?
-- 
stefan                                               PGP Key: 0xF59D25F0
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] portage on NetBSD

[Aaron Walker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Sperling wrote:
> On Fri, Apr 08, 2005 at 09:22:33AM +0200, Diego Flameeyes Petten� wrote:
> 
>>I was thinking of the virtual for future expansion on NetBSD and other, but 
>>this is probably better done using an || PDEPEND when it will be needed.
> 
> 
> That's interesting.
> Is anybody planning or working on a NetBSD port of portage?

Diego is more than welcome to play around with NetBSD, but officially the BSD
team decided to worry about getting one flavor working nicely before moving on
to porting another one.

- --
Bork Bork Bork!

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCVs49C3poscuANHARAjc6AJ9h6c2AsaIqs5wFKGXbVoVPkx8MDwCeKqPS
i1RvfuYG3khD6kPfJw/QjMs=
=LKMA
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] portage on NetBSD

[Diego "Flameeyes" Pettenò]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Friday 08 April 2005 20:32, Aaron Walker wrote:
> Diego is more than welcome to play around with NetBSD, but officially the
> BSD team decided to worry about getting one flavor working nicely before
> moving on to porting another one.
Actually, as I don't know anything about NetBSD (well, I knew nothing about 
FreeBSD, too), I'm not going to play with it soon :)
Was just a consideration as the same openpam is also used by NetBSD.

-- 
Diego "Flameeyes" Pettenò
http://wwwstud.dsi.unive.it/~dpetteno/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pluggable Hell Part 2: Fixing everything up!

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On Wed, 2005-04-06 at 23:38 +0200, Martin Schlemmer wrote:
> On Wed, 2005-03-30 at 22:15 +0200, Diego "Flameeyes" Pettenò wrote:

> > - the new ebuilds should add a new configuration file with the new syntax, and 
> > should depend on: || ( >=sys-libs/pam-0.78 virtual/pam ). This would fix the 
> > previous point, as who is using openpam will use the ~arch packages which 
> > will be fixed one by one (by me, submitting patches to maintainers), this way 
> > the packages will work out-of-the-box for both g/linux and g/fbsd users (i 
> > haven't searched on macosx, but should be, as they have the same userlands of 
> > fbsd).
> > 
> 
> Ugh, no - just more crud that somebody will have to clean out later.
> Like I said, get pam-0.78 and issues fixed, bumped to stable on all
> linux archs, and we can scourge the tree.
> 

Actually, its in ~, so should be fine if we want to start doing it.
Just keeping it synced might be an issue as as we can not depend on
>=pam-0.78 ...


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]