Re:

[Fletcher E Kittredge <fkittred@sss1.gwi.net>]

On Fri, 19 May 2000 12:11:27 -0700  Terry Lambert wrote:
> > On Thu, 18 May 2000 15:18:12 -0700  Terry Lambert wrote:
> > > Feel free to go into details; I'm familiar with all of
> > > the BSD's, being the author of the 386BSD 0.1 patchkit,
> > > which was the genesis of NetBSD (accidental) and FreeBSD
> > > (on purpose).  I've also been a BSDI user since it was
> > > first released.
> > 
> > Terry;
> > 
> > Flamewars are a waste of time and I know you are a very busy man with
> > better things to do.  Before we begin one (with you in a
> > disadvantageous position)
> 
> Note: I am now a subscriber to "bsdi-users", so they can now
> see my side of the conversation, as well as yours.

Makes sense; sorry to take so long to get back to this issue, but I
have been busy.

> I am personally only interested in solving the posters
> pronblem, and not in telling him why it can't be done
> right now.

We share the same goals.  I was trying to outline to Samson a
potential method of solving his problems, while taking care to
document the stuff that *should* work, vis the stuff I had actually
rigorously tested.  This might have come across as saying it couldn't
be done now, when what I was trying to avoid is having someone get
stuck on the bleeding edge.

> If you insist on pushing harder on it being impossible,
> I will implement the thing and publish it, providing an
> empirical proof of possibility.

Wow, we are really talking past each other.  I thought you were saying
that my method wouldn't work, and to use PAM.  I am certain that you
can get PAM to work with some programming on BSD/OS.  I did a
proof-of-concept that one could use the available tools on BSD/OS and
to avoid the PAM programming work.  Personally, I would take anyone
else's  proof-of-concept with a huge grain of salt, so feel free to
treat mine in the same manner.

> 
> > 1)  PAM is not available for BSD/OS, and probably never will be.
> >     BSD has their own (superior?) authentication architecture.
> 
> I'm aware of the "approve"/"approve-service"/"auth"/"auth-type"
> portion of login.conf in BSD/OS.  As Sean Eric Fagin, who wrote
> the same code for FreeBSD, partly from my goading him into it,
> can attest.

I applaud this effort!  I also apologize for overstating the lack of
availability of PAM above.  Naturally, anyone can do the work to add
PAM to BSD/OS themselves -- Turing machines and all that.  What I
should have said is I am pretty sure that PAM won't be supplied by the
OS vendor any time soon. 

> I was not suggesting using PAM for BSD/OS authentication,
> I was suggesting using PAM modules with a third party
> FTP server running on BSD/OS.
>
> Remember that _he does not want to authenticate users to the
> OS_, he only wants to authenticate users to his applications,
> and he in fact thinks that authenticating them to the OS is
> _highly undesirable_.  I happen to agree with this sentiment.

I remember do this :) I also am quite aware that following the method
I outlined, you could use LDAP/IRS/NSS to supply the /etc/passwd type
information to the OS, while still denying access via configuration of
the proper classes and values in /etc/login.conf.

> 
> It need not be PAM, however.  I had just assumed that he
> was using PAM for his FTP server, since he said it could
> do LDAP authentication.
> 

A reasonable assumption to make!  I look forward to the day when we
have a unified auth model :)

> 
> PS: I could _make_ PAM work as an "auth=" method in login.conf,
> if I were forced to do so, which totally bypasses IRS, just
> like the SecureCard module does.  This is not rocket science.

I agree!

> 
> > 2) *on BSD/OS 4.1*, read the man pages for Vixie's IRS (man 5
> >    irs.conf) and read up on the PADL NSS work.
> 
> OK, it can be used to transport all NIS data, including
> password maps.  I was wrong about it on BSD/OS.  Still, there
> is no LDAP support, so IRS is irellevant to the task at hand.

It appeared from the few tests I ran that you could use the PADL stuff
to supply LDAP to IRS via NSS.  Grain of salt time :)  Make that a
pickup truck full 'o salt.

> 
> Since he claims his FTP server already authenticates via
> LDAP using an RFC2307 schema, the UID from that schema is
> available to the FTP server for use in an seteuid() call;
> it doesn't matter whether it came in through PAM or some
> other method, the thing's available to the FTP server.
> 
> What he needs for FS quota enforcement is a quota file,
> quotas enabled, and a seperate UNIX UID entry for each of
> the quotas he wants to maintain seperately.
> 
> To get this, the quota mechanism requires that FS operations
> occur in the context of a set of UNIX credentials, which are
> just integers, and the system doesn't care where the integers
> come from, so long as they are set via set{e}[ug]id(0 calls.

Complete agreement.  This would work with the path I outlined.  I
agree with you that it would work if third-party PAM was supplied.

I apologize for the confusion I caused.  I thought you were saying
that my IRS/NSS/LDAP method would not work, and I understand now that
it sounded like I was saying that your method with third-party PAM
would not work.  I really didn't mean to say this.  Mea culpa :)

regards,
fletcher