The real pursuit is UNIX.  as it is.  Plain, simple, efficient, Good.  I'll
raise a point about a 2 services provided by NetBSD and my thoughts on
basically the same thing in both.

We'll start with, my personal current seemingly obsession, and I'm truly
sorry to keep bringing it up, but here we are again.  Maybe if we discuss a
little it will put things at ease.

/usr/libexec/httpd:

Excellent in concept and execution.  A Small, Simple, Fast process.  As it
should be.
I think things could be simplified, and obviously tightened.  I'd like to
get to know and understand the state of things, but I digress, let's get to
the point.

First, I raised the issue of some (nonsense) denial of service attack
regarding connections of long duration.  A time limit was put on the
connections.  I'm sorry.  This was nonsense, and basically
distructive hacker BS.  I think the timer should be removed.  Emphasis on
strong and simple.  If you want more, move to Apache.  In My Humble Opnion
of course, but for what it's worth, I feel strongly about it and am truly
apologetic.  I'm embarassed by the 90s "hacker" nonsense.

Anyway, on to my (humbly) UNIXish thoughts on this.  The user home
directory.

This is the request.
GET /~babylove/index.html

This is translated to retrieve the file at ~babylove/index.html.  Basically
this is nonsense and essentially useless.  Ok, user's web pages.  (nobody
cares).  I'm exausted so long story short, this request should retrieve
DOCUMENTROOT/~babylove/index.html, which 404 yadda likely.  I'd like to
figure out how to communicate how strongly I feel about this, but
essentially, Strong, Simple, Efficient.

Further, I'd like to forget chroot(2).  chdir(2?) to DOCROOT, and allow to
traverse up the directory tree.

Illustrated:
GET /../../etc/rc.conf.local
Given a DOCROOT of /var/www, will retrieve /etc/rc.conf.local.  I like
this.  Simple.  Efficient.  If you seek added precaution, persue Apache.
To much ticks for precaution that I (nor you) need.  Nobody does that
nonsense anymore and you won't find anything anyway.  Permissions are
tight.  (list of users -> password cracker -> don't really care.  (And
especially appretiation for blocklistd)).  It's basically impossible to
crack passwords -> "Just Distribute, etc." ->  persue Apache if you need
this.

Instead of using .htpasswd for a list of user accounts and passwords for
access to certain directories, I think the httpd distributed should pull
from user accounts from the system (passwd).  Simple.  except you need to
figure out how to confirm a password from an unprivileged account -> "but
local users can then crack against passwd in super-fast light-speed now" ->
don't care -> persue apache.

fix that scandir(3) thing or I'll make malloc(2) return NULL like it should
;) sorry, half-musing, but whatever.


Basically the same opinion on FTP.  User accounts are sent to the FTPROOT
and can traverse up the tree.  I like FTPROOT/bin, but whatever.  Basically
the same opinions here.  It's basically the same service anyway.  maybe
chroot(2) to FTPROOT is in order here.  But I don't really want User
Accounts directed to home directories.  This won't fly, I see now, because
of the marketable possibility of a Web Hosting Service Provider (but I
don't really want that either).  So I still like this point.

That's basically it, but 2 more points to close.

I don't want a Super-Configurable system.  I want a tight system.  I like
minimal.  I don't want super-configurable.  Too much Clock required.
Also, Absolutely no Offence in any way attended.  I respect the tie to
UCBerk, but I do not desire an Academic system in any way.  When I was in
school, they used Solaris to introduce you, and I, personally, for whatever
it is not worth, do not want NetBSD in there anyway.  I don't see the
future in Academia, however, if the SUS were taught and NetBSD were
branded/certified compliant/conformant/whatever, I think it would increase
the footprint, and put you actually further in Academia.

Sorry for the ramblings.  I'm exausted, but I do see the light at the end
of the Tunnel.

Sincerely and Truly Yours,
Justin Allen Parrott

PS I look forward to any and all comments on or off list.

Reply via email to