Re: [Auth]mds and Barry: MACS authorization

[Mario D. Santana]

Hello all.

John wrote:
> Well, that's going to make the manpower estimate I'm preparing a bit 
> more difficult as i need to judge the difficulty of converting one 
> module from PERL to C++.

That depends on what you mean by "modules." If you mean method adapters, 
the amount of work in the new release will be similar to the old 
release. If you mean core modules, it probably would take much less work 
to convert the new stuff than the old. The new stuff is OO enough that 
it would be a matter of changing syntax and finding replacement 
libraries. I think estimates based on the old code would be a little 
conservative for the new, but not too terribly far off the mark.

> Contrary to your opinion I don't believe a 
> rewrite to the extent set down in the core teams suggestion will be only 
> 1 man year, but then I'm not looking at the correct codebase.

Hmm. I probably have the wrong idea about what the rewrite consists of. 
And I can't find the coreteam's list archived?

> Despite the fact that it documents otherwise? Well, add another task to 
> the tasklist: reflect actual program into documentation.

Yes. The documentation is still valid for last release. As soon as
design, features and functionality stabilize, we'll update the docs. I
was hoping before the next release, but that might not happen. Release
early, release often. It's not something that's on the back burner, it's
just that we need something to document before we document it. There's
also a big reorg of the source tree in the works.

> > If anyone's 
> >interested, I can explain the ideas we've had for this -- they're fairly 
> >interesting.
> >  
> >
> Please do; I'd like to see how well they mirror the same notes I had, 
> but AFAIK were never implemented in FrePort. Seems like if I ask 
> questions for long enough MACS and FrePort will end up being the same 
> animal.

The motivation is that PAM only goes so far. You can authenticate and
authorize trivially, even expose profile information in useful ways like
environment variables. This works in 0.5a, mostly. It would be just as
simple to use the PAM framework to access other databases for which PAM
modules exist, though we have no code for that yet. But the real trick
would be to get macs integrated wholly and transparently into a unix
system. So we had two ideas.

The first would be to create a NIS/NIS+ frontend -- a address@hidden version of
ypserv. Then any system that integrates with ypbind can use address@hidden for 
all
its user/group id lookups and all that. A fairly simple file-system
frontend could authorize actions on files based on address@hidden GECOS, 
finger(1),
whois(1), and other lookups could also be authorized based on address@hidden
Interesting, but we're not relishing the thought of implementing YP.

So we thought making a glibc NSS plugin would be more fun. See
http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_588.html for some
details. This would have the (dis)advantage of working only with glibc, a
requirement we're OK with. The big problem with this is the number of
concurrent connections required to the servers; e.g., every time ls(1) is
run, another set of connections is opened. So we thought of making a
local daemon that multiplexes server connections. A new client library,
API-compatible with the current remote one, could be written to talk to
the local muxer via shared-mem or some such, instead of directly to the
servers via sockets. On machines where the number of open connections
could be a problem, the muxer is run and the remote client .so is
replaced with the muxing .so and Viola!

While we're on the topic, there are all kinds of front-end possibilities
for address@hidden There already exist XML-RPC and SOAP frontends. An LDAP
frontend, or an Active Directory frontend if that's possible, would let
clients of our friends in Redmond share in our joyful delights. As you
mentioned before, a Passport frontend is possible, but users have to work
to use it.

I'll stop now, and hope I'm making at least a little sense.

Cheers!

mds
-- 
San Francisco isn't what it used to be, and it never was.  -- Herb Caen