Subject: re: Read-only mode

From: [email-masked] (John Benjamins)
Date: Wed, 6 Oct 1993 11:18:34 -0400

Mark Crispin,

On Oct 5, 10:47pm, you wrote:
} Subject: re: Read-only mode
} On Tue, 5 Oct 1993 11:25:48 -0500 (CDT), Matt Simmons wrote:
} > 	Starting pine, ^Zing it to go do something else, and then
} > forgetting about the ^Z'd process until you try to start up pine again,
} > and then having to wait for it to try to talk to the other process only
} > to find that it can't and that both are RO and having to kill both is
} > rather annoying....  Could pine be fixed so that if it opens up and
} > notices that another pine is running, it asks if it can make the other
} > one RO?  This would save a lot of grief...
} 
} We agree that this is annoying, but none of the various alternatives which we
} have considered have been any better.  We'll look into this further, but for
} the time being the best thing is to avoid suspending Pine and forgetting about
} it!
}
}-- End of excerpt of Oct 5, 10:47pm

what we do here is run a perl script called pine.  it checks for a
file like /tmp/.\usr\spool\mail\loginname.  if this exists it uses
fuser (system V only, sorry) to kill the process that has the file
open.  it then exec's the REAL pine binary called pine.x.  well
actually it has a couple of prompts in it, to make it more friendly.
if it finds the lock file, it says that you already have a pine
session running.  it then gives you the option of killing the original
session and starting a new one, or starting pine in read-only mode.
this has worked very well for us.  we had to do this because many
people here use a terminal emulator on their pc's to login to the
mailhost and read their mail with pine.  unfortunately sometimes the
pc's will hang, get rebooted, etc.  these leave pine sessions running
on the mailhost, so the next time they login they are in read-only
mode.  this script gets around having to explain how to run
ps/grep/kill to get around the problem.  sounds like it would help for
this case as well.

i'll include the script here (from an sgi, needs tweaking to work on
sunos, etc.).

hope this helps.

#!/usr/bin/perl -P-   # -*-Perl-*-
 
# Set up variables
 
$Answer = not;
$Continue = not;
$Kill = no;
$User = $ENV{'USER'} || $ENV{'LOGNAME'} || (getpwuid($<))[0];
$LockFile = "/tmp/\.\\usr\\mail\\".$User;
$RealPine = "/usr/local/pine/bin/pine.exe";
 
open(TTYIN, "</dev/tty") || die "can't read /dev/tty: $!";
open(TTYOUT, ">/dev/tty") || die "can't write /dev/tty: $!";
select(TTYOUT);
$| = 1;
select(STDOUT);
 
# Handle signals
 
$SIG{'INT'} = 'IGNORE';
$SIG{'TERM'} = 'IGNORE';
$SIG{'TSTP'} = 'IGNORE';$SIG{'HUP'} = 'cleanup';
 
sub ignore {
    print "\nUnknown command\n\n";
}
 
sub cleanup {
    system "stty", 'icanon';
    system "stty", 'isig';
    system "stty", 'echo';
    system "stty", 'eol', '^@';
}
 
#
 
system "stty", '-icanon';
system "stty", '-isig';
system "stty", '-echo';
system "stty", 'eol', '^A';
 
# Look for the pine lock file in /tmp
 
if ( -f "$LockFile" ) {
    while ( $Answer eq 'not' ) {
        print TTYOUT "\
You have another copy of pine running.  This may be the result of rebooting \
your PC while you were logged in to mcmail.  In any case, do you want to kill \
the other session and start a new one? [y/n]: ";
        read(TTYIN, $Answer, 1);
        if ($Answer =~ /^y/i) { 
            print TTYOUT "\n";
            $Kill="yes"; 
        }
        elsif ($Answer =~ /^n/i) {
            while ($Continue eq 'not') {
                print "\n\
******** WARNING ******** WARNING ******** WARNING ******** WARNING ********\
\
Pine will now start in READ ONLY mode.  This means you will not be able to
change your inbox folder.  Are you sure you want to do this? [y/n]: ";
                read(TTYIN, $Continue, 1);
                print TTYOUT "\n";
                if ($Continue =~ /^y/i) {
                    &cleanup;
                    exec $RealPine, @ARGV;
                    die "Can't run $RealPine: $!";
                }
                elsif ($Continue =~ /^n/i) {
                    &cleanup ; exit;
                }
                elsif ($Continue =~ /^q/i) {
                    &cleanup ; exit;
                }
                else {
                    print TTYOUT "\nPlease answer with y or n only please\n";
                    $Continue="not";
                }
            }
        }
        elsif ($Answer =~ /^q/i) {
            &cleanup ; print "\n" ; exit;
        }
        else {
            print TTYOUT "\n\nPlease answer with y or n only please\n\n";
            $Answer="not";
        }
    }
}
 
# Kill the old one?
 
if ( $Kill eq "yes" ) {
    system '/etc/fuser', '-k', $LockFile;
}
 
&cleanup;
 
# If we get here, we want to start the real Pine executable
 
exec $RealPine, @ARGV;
die "Can't run $RealPine: $!";

-- 
 //  E. John Benjamins -- <[email-masked]>
// Calvin: "Verbing weirds language."
\\ Hobbes: "Maybe we can eventually make language a complete impediment
 \\         to understanding."

---

From: [email-masked] (Ken Weaverling)
Date: Mon, 18 Oct 1993 15:51:38 -0400

>>>--->  On Oct 18, 11:57, Mark Crispin wrote:
> 
> Because there are sites which deliberately, prevent the creation of .lock
> files, Pine can only hope that /bin/mail uses flock() locking.  Otherwise, the
> site's policy really is ``you can't have unprivileged programs accessing mail
> files.''  On such a site, either you make Pine run privileged (and run the
> risk with doing that), or take the risk of not having effective locking, or
> you run Pine on another system.  :-(

Hmmm, so what is the risk of setting pine setgid to mail then? 

> We would appreciate suggestions of how to handle this any better.  We don't
> think it is safe to make locking configurable; Pine should try all forms. 

That's understandable, but at least put a note in the docs that say if
you want .lock locking, pine must be installed setgid to mail. Then those
of us that do know can make an intelligent decision.

-- 
Ken Weaverling          [email-masked]
    Manager of Computer Services
   Stanton/Wilmington Campuses of
Delaware Technical & Community College

---

From: Mark Crispin <[email-masked]>
Date: Mon, 18 Oct 1993 13:34:03 -0700 (PDT)

> Hmmm, so what is the risk of setting pine setgid to mail then?

Pine does nothing to prevent abuse of being setgid to mail.  A setuid/setgid
program is supposed to check itself to make sure that system integrity is not
being compromised.  Pine was not designed to run with privileges.

> of us that do know can make an intelligent decision.

Some note should go into the documentation about what's going on, but I don't
think that *recommending* that Pine be setgid is doing anyone any favors.

Personally, I feel that protecting /usr/spool/mail is needless, not to mention
obnoxious; why should a system manager take it upon himself to forbid J.
Random User from writing (or using) his own mail program?

But thanks for the suggestion, there *should* be some documentation.

---

From: [email-masked] (Ken Weaverling)
Date: Mon, 18 Oct 1993 16:47:21 -0400

>>>--->  On Oct 18, 13:34, Mark Crispin wrote:

OK, I am curious now, (honest!)

Are you saying that the mail spool should be 777 (or at least with the
sticky bit set on)?   Then if so, what is to prevent users from copying
whatever files they want up to the mail spool, or someone creating
a mailbox of a user that hasn't had mail delivered to them yet,
chmod'ing it to 664 and then chown'ing it to that user? (Sys V allows
chown by users)

---

From: Mark Crispin <[email-masked]>
Date: Mon, 18 Oct 1993 13:54:39 -0700 (PDT)

> chmod'ing it to 664 and then chown'ing it to that user? (Sys V allows

This is my personal opinion ONLY!!!

Here's an alternative strategy:
 1) Create mail files for all users, and fix any system programs which presume
    to delete empty mail files.  [Pine does not delete empty mail files.]
 2) Consider disabling chown() for users.  Unprivileged chown() has several
    other security/denial-of-service implications, which is why BSD disabled
    it.  If necessary, have a setuid ``safe-chown'' program that makes extra
    checks before doing the operation (but note that BSD users have rarely
    complained about its absence).
 3) Make sure that your mail delivery program does not permit links to mail
    files, improper ownership, improper protection (600 only), etc.  Have a
    periodic task ensure that mail files are ``proper'' and that all users
    have mail files (creating if necessary).  Possibly also flag mail files
    which are caught in ``bad'' state and drop an alert to the user.
 4) Put in traps to catch people who try this stunt, and bop them on the head
    when you catch 'em.  A few well-publicized examples do wonders...
 5) Educate your users about the possibilities of forged mail, and that they
    should cast a skeptical eye at any mail that looks ``wrong''.  Maybe also
    educate them about not deleting their mail files.
 6) Create a non-adversarial relationship with your users.  It seems to me
    that sites that are the most concerned with preventing users from doing
    something that *may* be bad are the ones which end up with users who are
    always trying to ``beat the system''.

These 6 measures will do more towards achieving a reliable mail infrastructure
whose integrity is high than so-called ``magic bullets'' such as directory
protections.  It does require more work, which is why many sites seek out the
magic bullets.  But, in my opinion, the time invested in doing this is more
than paid back in the long run.

---

From: Hannu Martikka <[email-masked]>
Date: Tue, 19 Oct 1993 12:14:25 +0200

>>>>> "Ken" == Ken Weaverling <[email-masked]> writes:

---> On Oct 18, 11:57, Mark Crispin wrote:
Ken> Hmmm, so what is the risk of setting pine setgid to mail then?
In our system all the INBOX folders are rw for owner and mail-group
(660). Also the /usr/spool/mail is writeble only for mail-group.
If we set sgid for pine, then anyone can read any INBOX-file. :(
ie. you can read other users mail...

Elm works fine and it is sgid mail. Could it be possible to change
pine to work correctly with sgid set?

--
Regards from Goodi
______________________________________________________________________________
Internet: [email-masked]  / \  
Bitnet  : GOODGULF@FINFILES     // \\             \-\-\-\-\-\-\	oh5lhh
Hannu Martikka,Skinnarilankatu /// \\\ 	            |		on 70cm	
28 F17, 53850 Lappeenranta,SF /// | \\\_____________|________________________
Home Tel. +358-(9)53-251446	  | :) Lappeenranta University Of Technology |
------------------------------------------------------------------------------

---

From: Jos Vos <[email-masked]>
Date: Tue, 19 Oct 93 14:32:47 MET

> chmod'ing it to 664 and then chown'ing it to that user? (Sys V allows

Yes, and: I don't want my mailbox being deleted by other users!

-- 
--    Jos Vos <[email-masked]>   (UUCP: ...!{uunet,mcsun,sun4nl}!nlbull!jos)
--    Bull Netherlands, Professional Services, Amsterdam, The Netherlands

---

From: Jos Vos <[email-masked]>
Date: Tue, 19 Oct 93 14:31:27 MET

> of us that do know can make an intelligent decision.

I assume that making Pine setgid mail does not solve the problem.
When a lock exists, it'll just ignore it anyway.  Or am I wrong
(I didn't dig into the coding details yet)?