[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re:

Fletcher E Kittredge 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.

--

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

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


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

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.

If that's a bad assumption on my part, then so be it; mea
culpa.  8-).  That doesn't change the LDAP/FTP relationship,
only the interface by which that relationship is established.

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.


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

Nevertheless, if one is keeping track of "points"...


> So... I am quite willing to drop this one if you are :)

I'm willing to drop it as well; however, us dropping this
will not make the posters application work.  Neither will
"wait for a later release of BSD/OS".

Nominally authoritative people saying "it won't work"/"it
will work" are not helping the poster.

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.

This _will_ solve the problem that the poster was trying to
solve; I am using a similar setup in a proprietary and
unannounced product.


Do you agree that UNIX, including BSD/OS, does not care
about UIDs, excepts as integers that come in via set{e}[ug]id()
calls?

Do you agree that the quota system enforces on the basis of
credentials, not user names?

If so, what I propose will work, with a minor (perhaps only
one line, if there is a variable in scope) change to his FTP
server.


Regards,
-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- terry@whistle.com
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.