[OpenAFS] The Illusion of Security

[Rodney Dyer]

Sam,

At 08:29 PM 8/18/03 -0400, you wrote:
>Seems like this is a lot more work than fixing things correctly.  But
>you seem fairly interested in going to a lot of effort to have what
>I'd consider a fairly poorly designed solution.

Seems like we agree to disagree.  :)

"Ask me the questions, bridge-keeper.  I'm not afraid."*

I don't consider what I've done in poor design, or bad design, or whatever 
your opinion is.  I consider what I've done to be a "patch" over 
inconsistent environments derived from working as an experienced systems 
programmer in the trenches.  I like to keep my hands as far away as 
possible from sticky proprietary traps that companies lay open for you to 
get caught in.  This allows me the opportunity to move freely when times 
change.  Working at the level of process scripting is an acceptable 
practice in the industry.  It allows the highest level of abstraction in 
case things change.

I'm not wearing a developers shoes, I'm a systems programmer for a large 
collection of networked machines.  I'm not trying to create a software 
release for other sites to use.  I'm offering solutions that others in the 
same situation may find useful.

We've used this system for well over a year now without a hitch.  It's 
secure, reliable, easily modifiable.  If I had to take what I've done in 
scripting, and migrate it to C or C++, it would be much more complex and 
harder to deal with in-house, and every time we needed to make a change 
we'd have to recompile, with library dependencies both at compile and 
run-time.  If I want to pull "kinit" and "aklog" out and pop in MSKlog or 
GSSKlog no problem.  If I want to change my logging, or deny the user 
logon, no problem.  It's really a Swiss army knife approach.

I just don't think you "get it" because you probably don't wear the same 
shoes as I do.  You are trying to create a software application for a 
specific problem.  I'm trying to setup and manage the entire user process 
environment when they logon.  And, it needs to be changeable at the drop of 
a hat.

I do value your opinion.  I'm sorry if I seem to be such a jerk.  I got a 
bit annoyed when I found out that the Sun Solaris kinit supported stdin, 
and I had a knee-jerk reaction.  Some have already replied via personal 
email to my query on the OpenAFS list.  They don't want to get caught up in 
the debate, and I understand.  But they've been positive to my stance 
(unprovable of course because I'll refrain from divulging their names at 
their request out of professional courtesy).

"Please, please!  This is supposed to be a happy occasion!  Let's not 
bicker and argue about who killed who!"*

I don't want to get on your bad side.  The kerb stuff from MIT is 
good.  I've been an advocate many times.  I have this sneaking suspicion 
that you've already committed to your changes to the Windows prompter code 
and you can't turn back even if you wanted to because of entrenched 
use.  That's fine.  What I've got works and if I keep having to add in a 
line with every new version of kinit, then no problem.  We actually don't 
upgrade the client that much anyway.  The 1.3.1 version is the first 
upgrade we've done since 1.2.4.  I just thought it would be nice for those 
who may copy this system of mine to not have to modify kinit for stdin, 
that's all.  I'm a competent system programmer.  I'll get by just 
fine.  I'll just end up whinning a bit.  :(

Thanks for your support!

Rodney


* Monty Python's Holy Grail.