|
|
| Author |
Message |
| 25 new of 467 responses total. |
remmers
|
|
response 100 of 467:
| 
Aug 30 19:19 UTC 2004 |
To change the shell field in /etc/passwd in a reversible way, add an
x to the path: e.g. /bin/bash becomes /bin/bashx. If necessary,
/bin/bashx could by a symlink to some standard "no shell" shell.
|
albaugh
|
|
response 101 of 467:
|
Aug 30 19:24 UTC 2004 |
Speaking from ignorance, wouldn't expiring an account immeidately subject it
to being reaped during the next "cycle"?
|
janc
|
|
response 102 of 467:
|
Aug 31 00:56 UTC 2004 |
No and yes. Reaping is based on how long since the account was last
successfully logged into. We run a program periodically that removes all
accounts more than 90 days old (really two programs - reapcheck finds the
accounts to delete, zapuser deletes them). This is based on the "lastlog"
file, the same file that is printed when you finger a user and it prints the
last login date.
In most modern Unixes you can associate an expiration date with each account.
This is saved either in the /etc/shadow file (Linux) or in the
/etc/master.passwd file (BSD). After that date, it is no longer possible
to log into the account. Grex has never used this feature in the past.
Normal Grex accounts have no expiration dates. When I say expiring an
account, then I mean setting its expiration date to zero - January 1, 1976.
It then becomes impossible to log into the account.
If a reap is run a few days after the account is locked, it won't be deleted,
since it would likely only have been a few days since the account was logged
into. But eventually a locked account would be reaped, since it will
eventually have been idle for 90 days.
Except, come to think of it, I think we normally delete locked accounts faster
than that. I forget the rule.
|
albaugh
|
|
response 103 of 467:
|
Aug 31 21:08 UTC 2004 |
Thanks for the explanation.
|
pfv
|
|
response 104 of 467:
|
Sep 1 16:38 UTC 2004 |
I HATE that "password expiration" stuff - and if you ssh, it gets even more
weird.
Aged, Euthanized accounts are not even remotely a problem ;-)
Go, Janc,Go!
|
prp
|
|
response 105 of 467:
|
Sep 3 00:05 UTC 2004 |
Wouldn't changing the shell to notcsh, nobash, ... where these are
links to /etc/nologin give a better message than changing the expire
of the account?
Of course backtalk would have a slightly different check to make in
this case.
|
janc
|
|
response 106 of 467:
|
Sep 4 01:52 UTC 2004 |
My concern with changing the shell has more to do with whether or not there
are ways to log into accounts that are expired. There are so many way to log
in, and I'm not sure all recognize expiration.
|
janc
|
|
response 107 of 467:
|
Sep 4 02:02 UTC 2004 |
I've done a little work on upgrading pwauth, but time has been short. If only
one person is going to be working on your system, you'd do better to pick one
with less going on in his life. Anyway, the pwauth thing is a bit complex
because it's not a Grex-only piece of software like robocop, but something
I distribute to many users all over the net, so changes have to be made in
a portable, compatible manner. Which is a pain in the keester. Password and
account expiration seem to be handled in two different ways by different
version so of Unix - BSD derived systems that have a /etc/master.passwd file
use one system, while Sun and Linux systems that use a /etc/shadow file use
another. In OpenBSD, and many other versions of Unix there is a higher level
interface to all of these via the login.conf file, and openBSD has some nice
procedure calls where you can directly invoke these, but these calls seem to
be unique to OpenBSD, not available on FreeBSD or NetBSD. Of course, Linux
and PAM use PAM instead of login.conf (pwauth already supports PAM). FreeBSD
somehow seems to have both PAM and login.conf. I haven't figured out yet if
this is insane or not. I think for now I'm going to ignore login.conf and
write login.conf to use the lower level procedure calls to do checks for
account expiration itself. The joy of Unix.
|
cmcgee
|
|
response 108 of 467:
|
Sep 4 12:50 UTC 2004 |
This response has been erased.
|
cmcgee
|
|
response 109 of 467:
|
Sep 4 12:51 UTC 2004 |
This response has been erased.
|
naftee
|
|
response 110 of 467:
|
Sep 13 21:08 UTC 2004 |
OK.
|
janc
|
|
response 111 of 467:
|
Sep 30 03:35 UTC 2004 |
OK, it took me too long, but I now have a new version of pwauth, the
authenticator for backtalk installed. It has a couple new features:
* Authenticates through the login.conf method. For Grex this means
that it will recognize both the standard OpenBSD encrypted passwords
and weird Marcus encrypted passwords without us having to do
anything special to teach it about them - the mods we made to make
login work will now automatically work for pwauth too.
* It will now refuse logins if there is a /etc/nologin file in
existance.
* It will not allow logins to expired accounts or to accounts with
expired passwords.
The reason that this took longer is that pwauth is a shareware package
that I maintain. I wanted the Grex mods to be in the standard
distribution, but that means I have to do them in a much more thorough
manner - they need to be portable to non-OpenBSD systems and need to
be fully documented and need to be tested on multiple operating systems.
But this is all done, and checked into Grexdoc now.
|
janc
|
|
response 112 of 467:
|
Sep 30 03:42 UTC 2004 |
I have Orville write configured to keep it's wrttmp file in /var/run on
the new system. For some reason, the file disappears from time to time.
I haven't a clue why, but it breaks Orville. I moved the wrttmp file to
/var/log in hopes that whatever was eating it in the old location would
leave that alone.
|
janc
|
|
response 113 of 467:
|
Sep 30 03:45 UTC 2004 |
Correction to one of my previous posts: FreeBSD uses PAM, not
login.conf. Having muddled with them both quite a bit now, my vote is
for PAM. Though it has some issues (mainly because the original spec
writers were vague about some key details), it's really much nicer than
login.conf. Of course, they don't actually provide exactly the same
functionality.
|
janc
|
|
response 114 of 467:
|
Sep 30 03:48 UTC 2004 |
I think my next step is to update the "lockuser" admin script to expire
accounts instead of X-ing their passwords, using usermod instead of
pwauth. This should be quite easy.
After that, I guess I need to talk to Kip about exim.
|
janc
|
|
response 115 of 467:
|
Sep 30 04:21 UTC 2004 |
I notice that someone in the board minutes says we need to upgrade to
OpenBSD 3.6. OpenBSD 3.6 will be out in November, and I fully intend
to have nextGrex up before then. Looking down the feature list, I see
nothing that we can't live without. I have no plans to upgrade to 3.6.
|
janc
|
|
response 116 of 467:
|
Sep 30 04:38 UTC 2004 |
Applied some more OpenBSD security patches.
|
aruba
|
|
response 117 of 467:
|
Sep 30 05:07 UTC 2004 |
You go, Jan!
|
naftee
|
|
response 118 of 467:
|
Sep 30 05:12 UTC 2004 |
OH JAN
|
twenex
|
|
response 119 of 467:
|
Sep 30 08:30 UTC 2004 |
Thanks, Jan. Can't wait!
|
mary
|
|
response 120 of 467:
|
Sep 30 11:59 UTC 2004 |
Huge thanks, Jan. HUGE.
|
mooncat
|
|
response 121 of 467:
|
Oct 1 14:23 UTC 2004 |
Yeah, what Mary said- Thank you!!!
|
janc
|
|
response 122 of 467:
|
Oct 1 15:36 UTC 2004 |
Grex was down for backups when I went to work on lockuser yesterday,
which stopped me because I couldn't get the old lockuser source off
Grex.
So I skipped ahead to doing an exim install. Exim is the mail transport
agent (MTA) we want to use instead of sendmail. This is the hunk of
software that handles all the mail going in and out of the system. It
puts your incoming mail into your mailbox file for you to read, and
passes your outgoing mail to whatever system it is addressed to for
handling.
The copy of exim in the OpenBSD 3.5 ports tree is sadly out of date, so
I'm doing the install based on the tarball from exim.org. This is going
smoothly so far, but slowly since I am following my usual procedure of
writing scripts to do the installation/configuration instead of just
going in and doing it. But I think I'm close to having it up and
running.
However, there is one major modification to exim that I think we need -
the mailbox quotas.
When another system connects to Grex to deliver an email message, it
first gives a short description of the message - who it is for, how big
it is, etc - and then Grex gets to say if it will accept it or not. If
it accepts it, the message is transmitted over Grex's link to Grex.
Now exim does have code built in to set limits on how much mail a user
may have, but that check is done after the message has been transmitted
to Grex. This is not so good. One of the common scenarios where a
mailbox is filled up is if someone is getting mailbomb - thousands of
messages being sent to them. Probably pretty quickly the mailbox will
fill up, and the mailbox quota will prevent it from growing anymore, so
the mail disk won't get full and other users will still be able to
receive mail. But even after the mailbox is full, all those mail
messages will still be going over our net link, which with Grex's rather
slow net link is a big problem.
A related problem is what to do with the messages that don't fit in a
users mailbox. In the case of legitimate emails, we'd prefer to bounce
them back to the sender, so the sender knows they didn't go through. To
bounce the message after we have accepted it, we'd need to email it back
out. So each one goes over our net link twice. Furthermore, we have to
mail it back to the address on the "From" line. But, nearly all spam
has bogus addresses on the "From" line. It's either a non-functional
address or the address of some innocent person who knows nothing about
this (you probably occasionally get bounce messages that you never sent
- this is why).
The mailbox quota system Marcus did for old Grex was smarter. It
rejects the message earlier. When a system comes to Grex and asks if
we'll accept a message of a given size for a given user, it checks the
user's mailbox, and if it is full, rejects the message immediately. So
the message never gets transmitted over Grex's connection. Furthermore,
the disposal of the undeliverable message is the problem of the other
system, not of Grex. Since the other system is very likely the system
from which the message originated, it can usually do a much more
intelligent job of bouncing it back to the right system.
So Marcus's method is obvious far superior to the standard method, which
makes you wonder why the standard method is standard. Well, the problem
is that modern MTAs are built on a very modular architecture. The part
of the program that accepts mail from other computers is completely
isolated from the part of the program that delivers mail into local
mailbox files. So when we are accepting mail, we are in a piece of
software that doesn't know that mailbox files exist, and may not even
know exactly what it is going to do with the mail after it accepts it.
So to make this work in exim, I need to link these two isolated hunks of
code. The general scheme would be to have a database that keeps track
of the state of everyone's mailbox. At message accept time, we'd need
the ability to check this database to see if a user may recieve mail.
Then we need something to watch the user's mailboxes and keep the
database up to date. User's mailboxes mostly change in two ways - the
MTA adds things to them, and user's mail client programs (pine, etc)
take things out. I may well be able to modify exim to update the
mailbox everytime it delivers mail. I'm not going to modify all the
different mail clients though (heck, It's possible to read your mail
with "vi"). So probably there will be a daemon process that
periodically scans user mailboxes to update the database. I'm thinking
that that should scan all system mailboxes occasionally, but scan
recently logged in users more frequently (since on Grex you can only
read mail while being logged in).
There are a couple web pages around describing how various people did
this, but none of the ones I've seen exactly fit our needs. I also
thing there were some good ideas in Marcus's version that I'll want to
carry over. So I've got some software design work to do.
If all of this is too hard, maybe I'll just set up standard exim mailbox
quotas and bring nextGrex up with that, with the intention of doing
something better later. But I think this is important enough that I'd
like to take a shot at doing it now.
Another of Marcus's modifications to sendmail on old Grex was to put in
a limited amount of spam filtering that all works before accepting the
message. There are lots of ways to integrate spam filtering into exim,
but I'm uncertain of how well these will work for Grex. Many suck a lot
of CPU and could be bad with Grex's mail volume. Also many kinds of
spam filtering are best done on a per-user basis. Any message sent to
me in Chinese is probably spam, but that may not be the case for a
Chinese user. I think Grex needs to seriously think about a spam
strategy, but it's a large and complex project, that is going to require
a lot of thinking. I don't want it on the critical path to getting up
on the new system. So I plan to come up with no spam filtering.
Marcus's spam filters are much maligned for their ineffectiveness. I
guess we'll see how much spam they were catching after we lose them.
|
twenex
|
|
response 123 of 467:
|
Oct 1 16:22 UTC 2004 |
Doesn't the use of a non-OpenBSD copy of exim invalidate the policy of using
OpenBSD for security reasons?
|
aruba
|
|
response 124 of 467:
|
Oct 1 17:24 UTC 2004 |
Re #122: Thanks for the long explanation, Jan. Couldn't the accepting
module of exim just look at the user's mail file to get its size, thus
avoiding having to have a database and a scanning daemon? That sounds
complicated. Is it really that much slower to look up the size of a file in
our heirarchical mail structure than to look up the same thing in a
database?
|
