Re: [Netatalk-devel] UAMs: why the 'M'?

[Matthew K. <kel...@po...>]

	... hit "send" too quick.

For the record, I'm a big proponent of modular development. A well
written server architecture (see Apache2) should be lean and expose
enough to allow modules to do everything, thus allow Enterprise
installations to make dynamic changes without recompiling (or even
re-starting, in some cases). 

Since I mentioned the Apache2 architecture, I've been hacking at an ASIP
module for Apache2. It works "okay" as long as you're willing to accept
a few limitations (including the complete and total lack for anything
resembling a resource fork, and that the volumes are read-only, among
others). Even Samba is moving towards a more modular (although
"daemonized" is perhaps a better term for TNG) interface. I recommend
thinking hard about why "modules are bad". Yes, not every OS supports
them, but then again why not give them yet another reason to evolve.

Also, for a good lesson in abstract server architecture, take a look at
Apache2. I've been using it for a infrastructure for a number of server
projects I've had, and -wow- is it flexible and well-built.

On Wed, 2003-01-29 at 17:37, Matthew Keller wrote:
> Phil,
> 
> Please keep in mind that Netatalk was originally written by the
> University of Michigan for one purpose - To allow Mac client access to
> their UNIX-served resources. There are ***LOTS*** of places where things
> could be done better/different. The UAM model is legacy of their
> development, I believe. Also, to my knowledge, there are none of the
> "original" Netatalk developers from that period, so a lot of the
> questions asking "Why X and not Y?" will be unanswerable.
> 
> On Wed, 2003-01-29 at 17:25, Philip Edelbrock wrote:
> > Hi, I'm trying to wrap my head around the compatibility and 
> > building/porting issues of Netatalk.  One part of Netatalk is confusing 
> > to me: Why is user authentication in 'modules'?  The code is clever to 
> > do that, but I wonder why so much effort is spent on that?  Particularly 
> > since it doesn't build or port very well to many systems (like OS-X, for 
> > example).
> > 
> > BTW- Here is a good explaination of shared objects (.so files) calling 
> > functions in an app:
> > 
> > http://www.qnx.com/developer/articles/oct1901a/
> > 
> > The UAM system seems to use 'Solution 1', which seems to only work in a 
> > few environments.
> > 
> > Here are a couple reasons which I considered for why it is a good idea 
> > to have 'modules', and why I've discounted them as good reasons:
> > 
> > - Admin Flexibility (pick and choose the auth you want/need) - Run-time 
> > (config file) auth flexibility is just as simple (easier, in fact) w/o 
> > modules.  The complexity and problems in implementing this kind of 
> > system seems to not have any advantage over a simplier method.  
> > Compile-time flexibility is also just as simple (you are either 
> > compiling support for a particular auth or not, regardless of where that 
> > code is).
> > 
> > - Security (only use the auth code which is desired) - It seems like a 
> > good idea, on the surface, to only load and link to those auth functions 
> > which you need to use.  Unfortunately, though, it is easy to craft 
> > and/or replace the uams with malicious code which does such things as 
> > log passwords somewhere.  I would argue, in fact, that authentication 
> > code is perhaps the /last/ thing you want to externally load and run on 
> > the fly on a server?  Some of this could be discounted if afpd/libatalk 
> > was strict about permissions or ownership on the uams files, but it does 
> > not seem to check at all.  I also wonder how the uams work for 
> > user-space apps which use libatalk authentication functions?  Lastly, I 
> > would argue that auth code should be very simple and not wrapped around 
> > a clever system which isn't easy to understand (to prevent unintentional 
> > vulnerabilities).
> > 
> > - Development flexibiliy (easy to create new uams and add them) - I 
> > would argue that writing new uams is currently more complex than 
> > following a simplier and more straight-forward auth API.  Also, I doubt 
> > auth methods change so often as to warrant a special system which allows 
> > you to not have to recompile the whole project over.
> > 
> > I'm just wondering if I am missing something?  If not, would there be 
> > resistance to removing the UAM system (and just compile in the auth 
> > systems instead) in the effort to make the project more portable and 
> > easier to maintain?
> > 
> > 
> > Phil
> > http://www.baltra.org/
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Netatalk-devel mailing list
> > Net...@li...
> > https://lists.sourceforge.net/lists/listinfo/netatalk-devel
-- 
Matthew Keller
Enterprise Systems Analyst
Computing & Technology Services
State University of New York @ Potsdam
Potsdam, NY USA
http://mattwork.potsdam.edu/