[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Scripting question



On Tue, Jan 09, 2001 at 10:55:11AM +1100, Nathan Ridge wrote:
> yeah that is a option.  See the problem/reason I need this is I am
> having a problem whereas if a user gets a timeout whilst doing a POP3
> retrieve it locks their mailbox, but will not unlock, you can delete
> the pop.lock file, chmod the spool file, but will not unlock and for
> example, in pine, it reads that the mailbox is READ ONLY! and will
> not delete any mail, only ELM will delete the mail from a spool file
> whilst in this READ ONLY mode, have any ideas on where this would be
> set and why it does not unlock after time.

not surprising, because pine is broken. as a general rule, use mutt or
elm instead of pine.


there are several solutions to this problem, including:

1. teach your novice admins how to telnet to port 110, and how to drive
the POP protocol so they can login as the user and delete unwanted
messages.

2. install a web mail program and let the user handle the problem
themself (alternatively, only allow your staff to access the webmail
program if public access to web mail would be too great a load)

3. use "su -s" and write a wrapper script around elm (or mutt) which
takes a user name as an argument, and opens that user's mailbox file.
configure sudo to allow your novice admins to run that script as root.

by using sudo they only need to know their own password rather than
root's and/or the customer's password (and your customers should be
warned to NEVER give their password to anyone, including your staff)

an example with really primitive logging and error checking.

	#! /bin/sh

	# this script was written by Craig Sanders 2001.  
	# hereby placed in the public domain.

	# it was written on the spot for illustrative purposes only.  it
	# is completely untested but it should work (probably :).

	# make sure logfile is owned root.root and mode 600 or 640
	LOGFILE="/var/log/readmail.log"
	SCRIPTNAME="readmail.sh"

	function logit {
		HOST=$(hostname -s)
		TIME=$(date "+%b %d %H:%M:%S")
		echo "$TIME $HOST $SCRIPTNAME[$$]: $@" >>$LOGFILE
	}

	SPOOLDIR="/var/spool/mail"
	MBOX="$SPOOLDIR/$1"

	# prevent access to mailboxes where owner is a member of group staff
	if [ $( groups "$1" | grep -q " staff" ) ] ; then
		logit "unauthorised attempt by $USER to access staff mailbox $1"
		exit 1
	fi

	if [ -f "$MBOX" ] ; then
		logit "$USER opened mailbox '$1'"
		su -s /bin/bash - "$1" mutt -f "$MBOX"
		exit 0
	else
		logit "$USER attempted to open non-existant mailbox '$1'"
		echo "no such mailbox"
		exit 2
	fi


note that this script uses su's "-s" argument to override the shell
listed in /etc/passwd. see su's man page for details.

also note that due to the nature of elm & mutt it is very difficult (if
not impossible) to prevent the novice admin from gaining a shell under
the customer's UID. this probably isn't a big issue - if they can't be
trusted with that shell, then they can't be trusted to access the user's
mailbox either.

also, you can't really trust the $USER env var unless there is no way
for the user to change it (e.g. set it read-only in /etc/profile).

the script is a good *starting point* for appropriate paranoia
concerning people's mailbox files. you should never make it too easy
to access them, and should always log any such access. this helps to
prevent abuse.


finally, don't use a broken pop daemon which leaves stale poplock files
around. there are several good non-broken pop daemons around now. try
several and use the one you like most.

craig


--
craig sanders



Reply to: