File: answer.html

package info (click to toggle)
lg-issue15 2-3
links: PTS
area: main
in suites: hamm, slink
size: 1,448 kB
ctags: 122
sloc: ansic: 113; makefile: 30; sh: 3
file content (1636 lines) | stat: -rw-r--r-- 63,007 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> 
<html>
<head>
<title>The Answer Guy Issue 15</title>
</head>

<BODY>
<H4>&quot;Linux Gazette...<I>making Linux just a little more fun!</I>&quot;
</H4>
<P> <hr> <P> 

<!-- =====================================================================  -->
<center>
<H1><A NAME="answer">
<img src="../gx/ans.gif" alt="" border=0 align=middle>
The Answer Guy
<img src="../gx/ans.gif" alt="" border=0 align=middle>
</A></H1> <BR>
<H4>By James T. Dennis,
<a href="mailto:jimd@starshine.org">jimd@starshine.org</a><BR> 
Starshine Technical Services, <A HREF="http://www.starshine.org/">
http://www.starshine.org/</A> </H4> 
</center>

<p><hr><p>
<H3>Contents:</H3>
<ul>
<li><a HREF="./answer.html#fetch">fetchmail and POP3 Correction</a>
<li><a HREF="./answer.html#auto">Automated File Transfer over Firewall</a>
<li><a HREF="./answer.html#chown">chown Question</a>
<li><a HREF="./answer.html#copy">Copy from Xterm to TkDesk</a>
<li><a HREF="./answer.html#file">File System Debugger</a>
<li><a HREF="./answer.html#ipfrag">IP Fragmentation Attack Description</a>
<li><a HREF="./answer.html#mail">Mail Server Problem</a>
<li><a HREF="./answer.html#send">Mail and Sendmail</a>
<li><a HREF="./answer.html#mount">Mounted vfat File Systems</a>
<li><a HREF="./answer.html#pop">POP3 E-Mail</a>
<li><a HREF="./answer.html#pseudo">Pseudo Terminal Device Questions</a>
<li><a HREF="./answer.html#root">root login Bug in Linux</a>
<li><a HREF="./answer.html#again">Sendmail-8.8.4 and Linux</a>
<li><a HREF="./answer.html#wuftpd">wu-ftpd Problems</a>
</ul>

<p><hr><p> 
<!--================================================================-->

<a name="fetch"></a>
<h3><img align=bottom alt=" " src="../gx/ans2.gif">
fetchmail and POP3 Correction
</h3>
<P> <B> 
From: Eric S. Raymond, <A HREF="mailto:esr@snark.thyrsus.com">esr@snark.thyrsus.com</A>
</B> <P><B>  
One of your answers in this month's letters column was slightly in
error.
</B> <P><B>  
Fetchmail no longer has the old popclient option to dump
retrieved mail to a file; I removed it.  Fetchmail, unlike its ancestor
popclient, is designed to be a pure MTA, a pipefitting that connects a
POP or IMAP server to your normal, SMTP-based incoming-mail path.
</B> <P><B>  
Fetchmail's "multidrop" mode does what Moe Green wants.  It allows
fetchmail, in effect, to serve as a mail collector for a host or
subdomain.
</B> <P><B>  
Fetchmail is available at Sunsite, under the system/mail/pop
directory.
<a href="http://www.ccil.org/~esr">Eric S. Raymond</a>
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	Eric is the author (compiler) of _The_New_Hackers_Dictionary_
	a maintainer of the Jargon file (on which the NHD is based)
	and is the current maintainer of the termcap file that's
	used by Linux (and probably other Unix' as well).

	He's also the author of 'fetchmail'
-- Jim
<p><hr><p> 
<!--================================================================-->

<a name="auto"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Automated File Transfer over Firewall
</h3>
<B> 
From: Koen Rousseau, <A HREF="mailto:koen@kava.be">koen@kava.be</A> 
</B> <P><B>  
Hi,<BR> 
Because of the security risk involved when using rcp,
I disabled this service on our linux host. But the
main advantage of rcp (over the more secure ftp) is
that you can run it non-interactively (from cron
for example). Is there a way to "simulate" this
functionality with ftp?
</B> 
<P>
<img align=bottom alt=" " src="../gx/ans2.gif">
	Technically non-anonymous ftp isn't 
	more secure than rcp.  The security
	concerns are different.  (Unless you're 
	using the "guestgroups" feature of wu-ftpd).  
	Under some circumstances it is less so.  
<P> 
	FTP passes your account password across
	the untrusted wire in "clear text" form.
	Any sniffer on the same LAN segment can
	search for the distinctive packets that mark
	a new session and grab the next few packets --
	which are almost certain to contain the password.
<P> 
	rcp doesn't send any sort of password.  However
	the remote host has to trust the IP addresses
	and the information returned by reverse DNS 
	lookups -- and possibly the responses of the
	local identd server.  Thus it is vulnerable
	to IP spoofing, and DNS hijaacking attacks.
<P> 
	Ultimately any automated file transfer will
	involve storing a password, hash or key on each
	end of the link or it will involve "trusting"
	some meta information about the connection (
	such as the IP address or reverse DNS lookups
	of the incoming connections).  
<P> 
	If the initiating host is compromised it can
	always pass bad data to the remote host (the 
	target of the file transfers).  If the 
	remote host (the target) is compromised it's 
	data can be replaced.  So we'll limit our 
	discussion to how we can trust the wire.
<P> 
	I'd suggest that you look at ssh. Written 
	by Tatu Ylongen, in Europe (Finland?) this 
	is a secure replacement for rsh.  It comes 
	with scp (a replacement for rcp).
<P> 
	ssh uses public key cryptographic methods for 
	authentication (RSA) and to exchange a random 
	session key.  This key is then used with a 
	symmetrical algorithm (IDEA or your choice among
	others) for the end-to-end encryption through out 
	the session.  
<P> 
	It is free for non-commercial use.  You can grab
	a copy from ftp.cs.hut.fi (if I remember correctly)
	or via http://www.cs.hut.fi.  If you are in the 
	U.S. you should obtain a copy of the rsaref library
	from mit.edu (I don't remember the exact hostname there)
	and compile against that (this is to satisfy the patents
	license from RSA).  If you need a commercial license for
	it you should contact Data Fellows -- look at those web
	pages for details -- or look at http://www.ssh.com.
<P> 
	This combination may seem like overkill -- but
	it is necessary over untrusted wires.
<P> 
	It is possible to run rdist (the remote file 
	distribution program) over an ssh link.  This will 
	further automate the process -- allowing you to 
	push and pull files from or to multiple servers,
	recurse through directories, automate the removal
	of files, and only transfer new or changed files.
	It is significantly more efficient than just rcp
	scripts.
<P> 
	There are other methods by which you can automate
	file transfers within your organization.  One which
	may seem downright baroque is to use the venerable old
	UUCP.
<P> 
	UUCP can be used over tcp.  You create accounts on each host
	for each host (or you can have them share accounts in various
	combinations -- as you like).  In addition to allowing 
	cron driven and on demand file transfers using the 'uucp'
	command (which uses the UUCP protocols -- if you catch the
	distinction) you can also configure specific remote scripts
	and allow remote job execution to specific accounts.
<P> 
	UUCP offers a great deal of flexibility in scheduling
	and job prioritization.   It is extremely automation friendly
	and is reasonably secure (although the concerns about 
	text passwords over your ethernet are still valid).
<P> 
	You could also use a modern kermit (ckermit from Columbia
	University) which can open sessions over telnet and perform
	file tranfers through that.  kermit comes with a rich
	scripting language and is almost universally support.
<P> 
	It is also possible -- if you insist on sticking with
	ftp as the protocol -- to automate ftp.  You can use
	the ncftp "macro" feature by putting entries in the
	.ncftprc file.  This allows you to create a "startup"
	macro for each host your list in your rc file.  It is 
	possible to have multiple "host" entries which actually
	open connections to the same host to do different operations.
<P> 
	It is also possible to use 'expect' with your standard 
	ftp client shell. Expect is a programming languages built
	around TCL which is specifically focused on automating
	interactive programs.
<P> 
	Obviously these last three options would involve 
	storing the password in plain text on the host in 
	the script files.  However you can initiate the 
	connection from either end and transfer files both
	ways.  So it's possible to configure the more 
	secure host to initiate all file transfer sessions
	(the ones involving any password) and it's possible
	to set up a variety of methods for the exposed host
	to request a session.  (an attacker might spoof a 
	connection request -- but the more secure host 
	will only connect to one of it's valid clients -- 
	not some arbitrary host.
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
Example 1: <BR> 
Internet users can upload a file on our public linux
host on the Internet. A cron job checks at 10 minute
intervals if there are files in the incoming files
directory (eg /home/ftp/incoming). If there are files,
they would be automaticaly transfered to another
host on our secure network (intranet) for further
processing. With rcp this would be easy, but rcp
is not a secure service, so can not be allowed on a
public Internet host. It's "competitor", ftp, is more
secure, but can it be done?
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	This is a "pull" operation. 
<P> 
	In this context ftp, initiated from the exposed
	host and going to a non-anonymous account on 
	your internal host, would be less secure than
	rcp.  (presuming that you are preventing 
	address spoofing at your exterior routers).
<P> 
	I'd use uucp over tcp (or even consider running
	a null modem if the hosts are physically close
	enough) and initiate session from the inside.
	TCP wrappers can be used to ensure that all 
	requests to this protocol come from the appropriate
	addresses (again, assuming you've got your anti-spoofing
	in place at the routers).
<P> 
	TCP wrappers should also be used for your telnet,
	ftp, and r* sessions.
<P> 
	The best security would be via rdist over ssh.
<P><B>
<img align=bottom alt=" " src="../gx/ques.gif">
Example 2: <BR> 
We extract data from our database on the intranet,
and translate them into HTML-pages for publishing
on our public WWW host on the Internet. Again,
we wish to do this automaticaly from cron. Normally,
one would use rcp, but for security reasons, we won't
allow it. Can ftp be used here?
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	This would be a "push" operation.
<P> 
	Exactly the same methods will work as I've discussed
	above.
<P> 
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="chown"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
chown Question
</h3>
<P><B>
From: Terry Paton, <A HREF="mailto:tpaton@vhf.nano.bc.ca">
tpaton@vhf.nano.bc.ca </A>
</B> <P><B>  
Hi Jim....<BR>
My question concerns the chown command. The problem that I have is as 
follows:
</B> <P><B>  
In a directory that I have access to I have several files that I own and 
also have group ownership. I want to change the ownership and group to 
something else. I am also webmastr and in the weaver group.
</B> <P><B>  
example: filename is country.html rw- rw- r tpaton owner tpaton group
</B> <P><B>  
I want to change to owner webmastr group weaver.
The command I used is chown webmastr.weaver country.html
The response the system gives is Operation not permitted.
</B> <P><B>  
Any ideas how come??
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	Of course.  Under Unix there are two approaches to 
	'chown' -- "giveaway" and "privileged only."  Linux
	installations almost always take the later approach
	(as do most systems which support quotas).
<P> 
	You want the 'chgrp' command.
<P> 
	You can use 'chgrp' to give group ownership of files 
	away to any group of which you are a member.
<P> 
	Another approach is to use the SGID bit on the
	directory.
<P> 
	If you have a directory which you share among several
	users -- such as a staging area for your web server --
	you can set that directory to a group ownership of a
	group (such as 'webauth') and use the 'chmod g+s' 
	to set the SGID bit.  On a directory this has a special
	meaning.
<P> 
	Any directory that is SGID will automatically set the 
	group ownership of any files created in that directory to
	match that of the directory.  This means that your 
	webauthors can just create or copy files into the directory 
	and not worry about using the chgrp (or chown) commands.
<P> 
	I suspect that this is what you really wanted.  Note:
	You'll want your web authors to adjust their umask to
	allow g+rw to make the best use of these features.  
<P> 
	Also note:  if this doesn't seem to work you might want to 
	check your /etc/fstab or the mount options on that filesystem.
	This behavior can be overridden with options to the mount 
	command and may not be available on some filesystem types.
	It is the default on ext2 filesystems.
<P> 
	There is also a special meaning to the "t" (sticky) bit
	when it is applied to directories.  Originally (in the
	era of PDP-7's and PDP-11's -- on which Unix was originally
	written) the sticky bit was a hint to the kernel to keep
	the images of certain executable files cached in preference
	to "non-sticky" files.  The sysadmin could then set this
	bit on things like "grep" which were used frequently --
	giving the system a slight performance boost.
<P> 
	Given modern caching techniques, usage patterns, and 
	storage systems the "sticky" bit has become useless on files.
<P> 
	However, most modern Unix systems still have a use for
	the 't' bit on directories.  It modifies the meaning of the
	"write" bit so that users with the write option to a directory
	can only affect *THEIR OWN* files.
<P> 
	You should always set the 't' bit on /tmp/ and similar
	(world-writeable) directories.
<P> 
	Perhaps, one of these days will find a use for the 't'
	bit on files again.  I don't know of a meaning for the SUID
	bit on directories (but there might be one in some forms
	of Unix -- even Linux).  Notice that "sticky" is not the
	same as SUID or SGID.  This is a fairly common misnomer.
<P> 
-- Jim


<p><hr><p> 
<!--================================================================-->

<a name="copy"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Copy from Xterm to TkDesk
</h3>
<P>
<B> 
From: Steve Varadi, <A HREF="mailto:svaradi@sprynet.com">svaradi@sprynet.com </A>
</B> <P><B>  
I have a question maybe someone know simpler solution for this.
I'm using TkDesk because very easy to use and most of the keystroke same
as in Win95.
If I want to copy something from xterm to an editble file I do
following:
</B> <ol>
<li>Select area in xterm
<li>Open Emacs
<li>Paste recent selection
<li>Save file 
<li>Open this file with TkDesk Editor and working with it comfortable
like in Win95 enviroment. 
 </ol>
<P><B>  
Is it any simpler procedure to copy something directly from xterm to
TkDesk Editor???
</B> <P><B>  
Thanks: Steve
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	The usual way to paste text in X is to use the 
	"middle" mouse button.  If you're using a two-button
	mouse you'd want your X server configured to 
	"Emulate3Buttons" -- allowing you to "chord"
	the buttons (press and hold the left button then
	click with the other).
<P> 
	I realize that this is different than Windows and 
	Mac -- where you expect a menu option to be 
	explicitly available for "Edit, Paste" -- but
	this follows the X principle of "providing 
	mechanisms" rather than "dictating policy"
	(requiring that every application have an 
	Edit menu with a Paste option would be a policy).
<P> 
	Personally I always preferred DESQview and 
	DESQview/X's "Mark and Transfer" feature -- which
	was completely keyboard drive.  It let me keep my
	hands on the keyboard and it allowed me to make
	interesting macros to automate the process.
	It was also nice because the application wasn't
	aware of the process -- if you could see text on
	your screen -- you could mark and transfer it.
<P> 
	However this sort of interface doesn't currently exist
	for Linux or XFree86 -- and I'm not enough of a programmer
	yet to bring it to you.  So try "chording" directly 
	into the text entry area of your TkDesk window after
	making your text selection.  Remember -- you'll probably 
	have to press on the left button first and hold it while
	clicking on the other button.  If you try that in the
	other order it probably won't work (never does for me).
<P> 
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="file"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
File System Debugger
</h3>
From: Steven Mercurio, <A HREF="mailto:stevenm@voicenet.com">stevenm@voicenet.com </A>
<P> <B> 
What I want to do is take apart the CURRENT filing system down to the
layout of the superblock.  On an AIX by IBM machine we used a program
called FSDB.  I just want to try and get my hands on it and the filing
system layout.
</B> <P>
<img align=bottom alt=" " src="../gx/ans2.gif">
	FSDB would probably be "filesystem debugger."
	The closest equivalent in Linux would probably be 
	the debugfs command.
<P>
	If you start this with a command like:
<P>
		debugfs /dev/hda1
<P>
	   ... it will provide you with a shell-like interface
	   (similar to the traditional ftp client) which provides 
	   you about forty commands for viewing and altering
	   links and inodes in your filesystem.  You can also 
	   select the filesytem you wish to use after you've
	   started the program.
<P>
	From the man page:
	       debugfs was written by Theodore Ts'o, tytso@mit.edu.
<P>
	There is another program that might be of interest to you.
	It's called lde (Linux Disk Editor).  This provides a 
	nice ncurses (with optional color) interface to many of the
	same operations.  You can find lde-2.3.tar.gz at any of 
	the Sunsite mirrors.
<P>
	There is yet another editor which is included with 
	some versions of Red Hat (and probably other distributions)
	called ext2ed.
<P>
	There are also FAQ's and HOWTO's on the ext2fs structure
	and internals available.
<P>
	Hope that helps.
<P>
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="ipfrag"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
IP Fragmentation attack description 
</h3>
<P> <B> 
From: Fabien Royer, <A HREF="mailto:fabien@magpage.com">
fabien@magpage.com </A> 
</B> <P><B>  
Hi all ! <BR> 
</B> <blockquote> <I><B> 
IP fragmentation is an old attack, used to send data to a port behind 
a packet filtering 'firewall'.
</B> </I> </blockquote>  <B> 
Now, wouldn't be possible to prevent an attack by packet fragmentation by
simply adding a second router that would receive and recheck the packets
reassembled by the first one ?
</B> <P><B>  
Regards, Fabien.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	Most routers don't do reassembly and most packet 
	filtering systems don't track connections.  In 
	these each packet is judged purely on its own 
	merits.
<P>
	There is a newer, more advanced class of packet
	filtering packages which do "stateful inspection."
<P>
	These are currently mostly implemented in software on 
	various sorts of Unix systems.  From what I've heard
	these are largely experimental at this point.
<P>
	 For those that are curious there is a team working
	 on a "stateful inspection module" for the Linux 
	 2.x kernel.  The "IP Masquerading" features that are
	 built into this kernel (A.K.A. "Network Address 
	 Translation" or NAT) provide most of the support 
	 that's necessary to "stateful inspection." 
<P>
	 Here's a couple of links (courtesy of the Computer:
	 Security section of Yahoo, and Alta-Vista):
<P>
	 
	CYCON Labyrinth Firewall 1.4 Announcement 
		http://www.cycon.com/press/announce.html
	CheckPoint FireWall-1 Brochure 
		http://www.checkpoint.com/brochure/page6.html
	Network Address Translation 
		http://www.oms.co.za/overview/node2.html
	Firewall Overview 
		http://www.morningstar.com/secure-access/fw101.htm
	Freestone Firewall for Linux
		http://www.crpht.lu/CNS/html/PubServ/\
		Security/Firewall/FW_Mail/07-16_freestone_SOS
<P>
		(note: that last one is one long line).
<P>
	(There is also a package called the Mazama Packet Filters
	for Unix/Linux -but I didn't see if it supports the 
	"stateful" stuff).
<P>
	I didn't find anything on stateful packet filtering under
	NT -- but Checkpoint's Firewall-1 (listed above) is 
	available for NT -- and might support it.
<P>
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="mail"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
</h3>
Mail Server Problem
<P> <B> 
From: Panoy Tan
</B> <P><B>  
Hi,<BR> 
First let me say that I enjoy Linux Journal very much and get a lot 
out of every issue, esp. 'Letters to the Editor'.
If you have time to help me, I will be very glad and here is my 
trouble : 
My mail server run Linux Red Hat with kernel 2.0 and I use Netscape 
Mail  (POP-user) to read my e-mails on the server.
POP was designed to support "offline" mail processing, not "online" and 
"disconnected", therefor I have problem when I read my e-mails with 
different computers. That, I need, is my mails have to leave on the 
mail server, but whenever I delete one of my mails, which 
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	This has become a recurring problem in the years
	since POP (post office protocol) was created.
<P>
	You can configure most POP clients to keep your 
	mail -- but then you'll be downloading a new
	copy of every message to each machine -- each time
	you connect.
<P>
	Apparently (searching through Netscape's site) there
	is a hack to the POP3 protocol which would allow
	some of what you're looking for.  This appears to be
	called UIDL:  Here's what I read:
<P>
<A HREF="http://help.netscape.com/kb/client/960626-31.html">
             "The POP3 server does not support UIDL"</A>,
   Issue: 960626-31 Product: Navigator, Navigator Gold, Personal Edition,
                       Created: 06/12/96
<P>
	Unfortunately they didn't have any pointers to a 
	POP server with UIDL support.  A search at Yahoo!
	sent me straight to Alta Vista -- so a number of USENet
	and mailing list postings that referred to a variety of
	patches.  I'll leave that as an exercise to the reader.
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
I have read, it will be delete from the server.
I have heard that IMAP supports 'online' mail processing and that is 
reason to my questions :
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	I've heard similar rumors.  The question I was trying
	to answer by looking at Netscape's site is whether they 
	support the client side of IMAP.  Here's some more
	background info:
<P>
	IMAP (Internet Mail Access Protocol) is intended to be
	a more advanced mail service.  The proposed standards
	are covered in RFC1730 through RFC1733 (which are 
	conveniently consecutive) and RFC2060.  You can search
	for RFC's at the ds.internic.net web site or use 
	ftp.isi.edu.
<P>
	RFC's are the documents which become the standards of the
	Internet.  They start as "requests for comments" and 
	are revised and into STD's (standards documents) and
	FYI's ("for your information" documents).  In the anarchy
	that is the 'net -- these are the results of the "rough
	consensus and running code" that gets all of our systems
	chatting with one another.
<P>
	I did a quick Yahoo search using the keywords IMAP and Linux
	and came up with the following:
<blockquote> 
<A HREF="http://www.imap.org/whatisIMAP.html">whatisIMAP?</A> 
   IMAP stands for Internet Message Access Protocol. It is a method of
   accessing electronic mail or bulletin board messages that are kept on
   a (possibly shared) mail server. In other words, it permits a "client"
   email program to access remote message stores as if they were local.
   For example, email stored on an IMAP server can be manipulated from a
   desktop computer at home, a workstation at the office, and a notebook
   computer while traveling, without the need to transfer messages or
   files back and forth between these computers.
<P> 
   IMAP's ability to access messages (both new and saved) from more than
   one computer has become extremely important as reliance on electronic
   messaging and use of multiple computers increase, but this
   functionality cannot be taken for granted: the widely used Post Office
   Protocol (POP) works best when one has only a single computer, since
   it was designed to support "offline" message access, wherein messages
   are downloaded and then deleted from the mail server. This mode of
   access is not compatible with access from multiple computers since it
   tends to sprinkle messages across all of the computers used for mail
   access. Thus, unless all of those machines share a common file system,
   the offline mode of access that POP was designed to support
</blockquote>
<P>
	There is *much* more info at this site -- I only clipped
	the first two paragraphs.
<P>
	Some related work is the ACAP (Application Configuration 
	Access Protocol) and the IMSP (Internet Message Support 
	Protocol) which are other drafts that are currently on 
	the table at the IETF (www.ietf.org).
<P>
	To quote another site that came up in my search:
<blockquote> 
<A HREF="http://andrew2.andrew.cmu.edu/cyrus/acap/">
   ACAP</A> is a solution for the problem of client mobility on the 
   internet. Almost all Internet applications currently store 
   user preferences, options, server locations, and other 
   personal data in local disk files. These leads to the 
   unpleasant problems of users having to recreate configuration 
   set-ups, subscription lists, addressbooks, bookmark files, 
   folder storage locations, and so forth every time they change 
   physical locations.
</blockquote> 
<P>
	If you're getting confused -- don't worry -- we all
	are.  I've been bumping into references to IMAP, and
	ACAP for a few months now.  They are pretty new and 
	intended to address issues that only recently grew 
	up to be problems for enough people to notice them.
<P>
	The short form is:  IMAP is an advanced protocol for 
	accessing individual headers and messages from a remote
	mail box.  ACAP (which I guess replaces or is built over
	IMSP) provides access to more advanced configuration
	options to affect how IMAP (and potentially other 
	remotely accessed applications) behave for a given account.
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
1) Is there any IMAP to Linux, esp. Red Hat ?
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	There is an IMAP server included with Linux some
	Linux distributions (Red Hat 3.03 or later I suspect).
	I'm not sure about the feature set -- and the 
	man page on my Red Hat 3 system here is pretty sparse.
<P>
	However the server is not the real problem here.
	What you really need is a client program that can
	talk to your IMAP server.
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
2) Where can I get it ?
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	The CMU (Carnegie-Mellon University) Cyrus IMAP project
	looks promising  -- so I downloaded a copy of that
	as I typed this and looked up some of these other references.
<P>
	It's about 400K and can be found somewhere at:
<P>
		ftp://ftp.andrew.cmu.edu/
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
3) What must I be carefully when I install it ?
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	You must have a client that supports the IMAP features 
	that you're actually looking for.  It's possible to 
	have a client that treats an IMAP server just like a 
	POP3 server (fetchmail for example). It may be that
	Netscape's UIDL support is all you need for your
	purposes.
<P>
	I didn't find any reference to IMAP anywhere on
	Netscape's site -- which suggests that they don't 
	offer it yet.  I'm blind copying a friend of mine
	that is a programmer for them -- and specifically
	one who worked (works?) on the code for the mail
	support in the Navigator.  Maybe he'll tell me 
	something about this (or maybe it's covered by his
	NDA).
<P>
	I also looked at Eudora and Pegasus web pages and
	found no IMAP support for these either.  It was a 
	long shot since neither of these has a Linux port
	(so far as I know) -- and I doubt you want to run
	WABI to read all of your mail -- nor even DOSEmu
	to run the Pegasus for DOS.
<P>
	pine seems to support IMAP.  XF-Mail (a popular
	free X mail user agent) and Z-Mail (a popular
	commercial one) also seem to have some support.
	More info on IMAP clients is available at the 
	IMAP Info Center (see below).
<P>
	The most informative web sites I visited in my
	research for this question were:
<P>
	   Cyrus IMAP Server:  Overview and Concepts
		http://andrew2.andrew.cmu.edu/cyrus/cyrus-overview.html
	   The IMAP Information Center
		http://www.imap.org/
	   Draft IMSP Specification
		http://andrew2.andrew.cmu.edu/cyrus/rfc/imsp.html
	   The ACAP Home Page
		http://andrew2.andrew.cmu.edu/cyrus/acap/
	   Client-server mail protocols FAQ
		http://www.cis.ohio-state.edu/hypertext/faq/ \
		   usenet/mail/mailclient-faq/faq.html
<P>
	The most active discussion about UIDL seems to have been on 
	the mh-users mailing list.  Archives can be found at:
	http://www.rosat.mpe-garching.mpg.de/mailing-lists/mh-users/
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
Thank you for your time to read my questions and hope to hear you 
soon.<BR> 
Regards, Nga   
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	It's a hobby.  I really only had about 2 hours to spare on this
	research (and I took about three) -- and I don't have an 
	environment handy to do any real testing.
<P>
	As I said -- I've been bumping into references about 
	IMAP and ACAP and wanted to learn more myself.  At the last
	IETF conference (in San Jose) I had lunch with one of the
	sysadmins at CMU -- who talked a bit about it.
<P>
	Sorry this article is so rambling and disorganized.  
	I basically tossed it together as I searched.
	
	To paraphrase Blaise Pascal:
<blockquote> 
		This letter is so long because I lack the
		time to make it brief.
</blockquote> 
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="send"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Mail & Sendmail 
</h3>
<P> <B>
From: Franaur P. Tan, <A HREF="mailto:noy@ayala.com.ph">noy@ayala.com.ph
</A>
</B> <P><B>  
Hi There, <BR> 
I just read your article on Linux Gazette, got a lot of
good tips on securing my Linuz machine, thanks.  Like
always, I have one bit of question I was hoping you could
answer, I'd like to send mail from my Linux machine w/o
installing sendmail, and I need this e-mail to be sent
by a script initiated by crond.
</B> <P><B>  
Right now (w/ sendmail installed) I can do it with
a "mail -s subject noy@ayala.com.ph < my_message".
I'd really like to remove sendmail from my system.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	Which article?  I'm trying to submit at least
	one a month.
<P>
	Well, you can use smail or qmail.  These are
	replacements for sendmail.  
<P>
	I haven't installed either of these but I've 
	fetched a copy of qmail and read a bit of the 
	documentation.  I might be implementing a 
	system with that pretty soon.
<P>
	However I'm not sure how much you gain this
	way.  It's possible to configure 'sendmail'
	to send only so that it doesn't listen to 
	incoming mail at all.  This is most easily
	done by simply changing the line in your 
	rc files that invokes sendmail (that would be
	/etc/rc.d/init.d/sendmail.init on a typical
	Red Hat or Caldera system).  Just take the 
	"-bd" off of that line like so:
<PRE> 
		/usr/lib/sendmail -bd -q1h
</PRE> 
	... would become:
<PRE> 
		/usr/lib/sendmail -q1h
</PRE> 
	... or
<PRE> 
		/usr/lib/sendmail -q15m
</PRE> 
		(changing the queue processing frequency 
		from every hour to every 15 minutes).
<P>
	You can also remove sendmail from memory entirely
	and use a cronjob to invoke it like:
<PRE> 
	00,30 * * * * root /usr/lib/sendmail -q
</PRE> 
		(to process the queue on the hour and at
		 half past every hour).
<P>
	If you concerns are about remote attacks through 
	your smtpd service than any of these methods will
	be sufficient.  
<P>
	You should also double check your /etc/inetd.conf for 
	the smtp service line.  This is normally commented out 
	since most hosts default to loading a sendmail daemon.  
	It should stay that way.
<P>
	If you are using fetchmail (and getting your 
	mail via POP or IMAP) you either after to load
	some sort of smtp listener (such as sendmail,
	smail, or qmail) or you have to over-ride 
	fetchmail's defaults with some command line
	options.
<P>
	'fetchmail' defaults to a mode whereby it 
	connects to the remote POP or IMAP server,
	and to the localhost's smtpd and relays the 
	mail from one through the other.  This allows
	for any aliases, .forwards, and procmail processing
	to work properly on the local system and it 
	allows fetchmail to benefit from sendmail's 
	queue handling (to make sure you have sufficient
	disk space etc).
<P>
	However you can configure sendmail to run out 
	of in inetd.conf with TCP Wrappers (the tcpd entry that 
	appears on almost all of the other services in that file) 
	and limit the listener to only accept connections from 
	the local host.
<P>
	You'd then configure your /etc/hosts.deny file
	to look something like:
<PRE>
		ALL:ALL
</PRE> 
	... spr  (default to not letting anyone access any
	local services) -- and you'd put something like:
<PRE> 
		ALL: localhost
		in.telnetd: LOCAL
		in.ftpd: LOCAL
</PRE> 		
	... etc. in your /etc/hosts.allow
<P>
	Finally you'd add something like:
<PRE> 
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sendmail -bs 
</PRE> 
	... to your /etc/inetd.conf.  
<P>
	(the -bs switch tells sendmail to "be" an "smtp"
	 handler for one transaction.  It handles one 
	 connection on stdin/stdout and exits).
<P>
	 All of this discussion assumes that you want to
	 be able to use local mailers (like elm, and mailx)
	 to send your mail and fetchmail to fetch it 
	 from a POP or IMAP server.
<P>
	If your client is capable of it (like the 
	mail reader in Netscape) you could configure
	it to use a remote smtpd gateway directly
	(it would make the connection to the remote
	host's smtp port and let it relay the mail from
	there).  Then you'd have no sendmail, qmail, or
	smail anywhere on the system.
<P>
	pine might be able to send directly via smtp
	(it does have an IMAP client so this would be a
	logical complement to that).
<P>
	I hope all of this discussion gives you some ideas.
	As you can see there are lots of options.
<P>
-- Jim 

<p><hr><p> 
<!--================================================================-->

<a name="mount"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Mounted vfat filesystems 
</h3>
<P> <B> 
From: Steve Baker, <A HREF="mailto:ssbaker@mwr.is">ssbaker@mwr.is </A> 
</B> <P><B>  
I have 2 vfat filesystems mounted. They belong to root; is there any way
to give normal users read/write access to these filesystems? chown has
no effect on vfat directories and files.
</B> <PRE><B>  
man 8 mount
</B> </PRE> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	I think this answer was a waste of bandwidth.
	Perhaps Andries didn't know this -- or perhaps he
	tried and the man page didn't make any sense.
<P>
	In either event it doesn't do a thing for any of us 
	(that didn't know the answer) and is an obvious and
	public slap in the face.
<P>
	You could have at least added:
<P>
		'look for gid= and umask= under options'
<P>
	Me, I don't know these well enough so let me 
	switch over to another VC, pull up the man page myself,
	and play with that a bit...
<PRE> 	
	mount -t msdos -ogid=10,umask=007 /dev/hda1  /mnt/c
</PRE> 
	This command mounts a file system of type msdos (-t)
	with options (-o) that specify that all files are to 
	be treated as being owned by gid 10 ('wheel' on my system)
	and that they should be have an effective umask of 007
	(allowing members of group 'wheel' to read, write and 
	execute anywhere on the partition.  My C: drive is 
	/dev/hda1 and I usually mount it under /mnt/c.
<P>
	I tried specifying the gid by name -- no go.  You have to 
	look up the numeric in the /etc/group file.  I tried
	different ownership and permissions on the underlying 
	directory -- they are ignored.
<P>
	This set of parameters does seem to work with vfat and
	umsdos mountings.  Using the msdos or vfat at the time
	means that chmod and chown/chgrp commands dont' work
	on that fs.  Using the -t umsdos allow me to change the 
	ownership and permissions -- and the changes seem to be
	effective.  However there are some oddities in what happens
	when you umount and remount the drive (the move of the 
	write permission on files seems to stick but the ownership
	changes are lost and the owner/group r-x bits seem to 
	"come back."
<P>
	Obviously I haven't done much testing with this sort of 
	thing.  I usually don't write to my DOS partitions 
	from in Linux.  In fact I haven't see my DOS hard drive
	partition on this system in months (ever since I started
	compiling the msdos, vfat, and umsdos filesystems as 
	modules -- so I don't  automount them).
<P>
	I hope that helps.
<P>
	Personally I wish that the mount command would take some
	hints from the permissions of the directory that I'm 
	mounting onto.  I'm copying you two on this in the hopes
	that you'll share your thoughts on this idea.
<P>
	What if the default for mount was to set the gid and umask
	of an msdos/vfat directory based on the ownership and 
	permissions of the mount point.  In other words I set up
	/mnt/c to look like:
<PRE> 
drwxrwx---   2 root     wheel        1024 Aug  5  1996 c
</PRE> 
	(which I have) and mount would look up the gid for 
	wheel and use that and the umask for the mount options.
<P>
	This strikes me as being a reasonably intuitive behaviour.
<P>
	If it can't be the default how about an option like:
<PRE> 
		-o usemountperms
</PRE> 
	... (that particular example seems a little ugly -- but
	fairly self-explanatory).
<P>
-- Jim
 

<p><hr><p> 
<!--================================================================-->

<a name="pop"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Re: Answer Guy - POP3 Email 
</h3>
<B> 
From: Brent Austin, <A HREF="mailto:baustin@iamerica.net">
baustin@iamerica.net </A> 
</B> <P><B>  
In reading your answer in LG#14 on "Dealing with e-mail on a pop3 server",
I have almost the same challenge.  I have an ISP that is providing a 25
user POP3 Virtual Mail Server for 25 users.  The problem is that each user
must connect with the ISP individually and then to the mail server.
I would like to find some method to allow Linux to connect with the Mail
Server, individually poll each users account, and then transfer it into a
POP3 server
on the local network (possibly on the Linux box itself).  Any suggestions??
</B>
<P>
<img align=bottom alt=" " src="../gx/ans2.gif">
	If I understand you correctly you have a LAN at your 
	place with about 25 users/accounts on it.
	You're provider has set up 25 separate POP3 mailboxes.
<P> 
	You'd like to set up your Linux (or other Unix) box to
	fetch the contents of all of these accounts (perhaps via
	a cron job) and to have it process your outgoing mail queue.
<P> 
	Then your users would fetch their mail from the Linux
	box (using their own Linux user agents or perhaps using
	Pegasus or Eudora under Windows or from Macs.
<P> 
	This is relatively straightforward (especially the POP3 
	part).
<P> 
	First get a copy of 'fetchmail' (I'm using 2.5 from 
	ftp://sunsite.unc.edu).  Build that.
<P> 
	Now, for each user, configure fetchmail using a 
	.fetchmailrc file in their home directory
<P> 
	Each will have a line that looks like:
<PRE> 
poll $HOST.YOURISP.COM proto pop3 user $HISACCT password $HISPASS
</PRE> 
	The parts of the form $ALLCAPS you replace with 
	the name of the pop server, the account holder's name
	and the account holder's password.  (I presume that  you,
	as the admin for this Unix box, are already entrusted
	with the passwords for these e-mail accounts -- since
	the admin of any Unix box can read any of the mail flowing
	through it anyway).
<P> 
	Now set up a script run as root that does something like:
<PRE> 

	##! do mail psuedo-code
	pppup (some script that brings up your PPP link)
	for users in $USERLIST do;
		[ -e ~$user/.fetchmailrc] && \
			su -c $user /usr/local/bin/fetchmail
		done;
	/usr/lib/sendmail -q		
	pppdown
</PRE> 
	You can add a section of code that graps the list
	of users from your /etc/group file (if you're writing 
	this in perl use the getgrent function (to get group
	entries) or you can use something like:
<PRE> 
	
	awk -F":" '/'$GROUPNAME\
		'/ {split($4,users, ","); 
		for (a in users) {print users[a]}; exit}' /etc/group
</PRE> 
	To get the list of users in a form suitable for 
	use in your 'for' loop.
<P> 
	Naturally my psuedo-code is closer to bash' syntax.
<P> 
	This script  (the psuedo-code one) will just bring the 
	ppplink up, for each user in the list (perhaps from a 
	group named "popusers") it will check for a .fetchmailrc
	file in their home directory and run fetchmail for those
	that have one.  It will then call sendmail to process your
	outgoing queue and bring the ppplink down.
<P> 
		(Note: the su -c ... part of this is not
		secure and there are probably some exploits
		that could be perpetrated by anyone with 
		write access to any of those .fetchmailrc's.
		However it's probably reasonably robust
		-- and you could set these files to be 
		immutable (chattr +i) and you can write
		a more secure SUID perl script to actually
		execute fetchmail.  My scripts, pppup and 
		pppdown are SUID perl scripts.
<P> 
	I haven't written this as real code and tested it since
	I don't have a need of it myself.  I recommend that 
	disconnected networks avoid using POP/SMTP for their 
	mail feed.  UUCP has been solving the  problems of 
	dialup mail delivery for 25 years and doesn't involve some 
	of the overhead and kludges necessary to do SMTP for 
	intermittently connected systems.
<P> 
	I do recommend POP/SMTP within the organization and 
	and it's absolutely necessary for the providers.
<P> 
	Anyway -- fetchmail will then have put each user's
	mail into his or here local spool file (and processed
	it through any procmail scripts that they might have 
	set up).
<P> 
	Now each of your users can use any method they prefer
	(or that you dictate) to access their mail.  DOS/Windows
	and Mac users can use Pegasus or Eudora, Linux or other
	Unix users can use fetchmail (or any of several other
	popclient, getpop, etc, other programs) to get the
	messages delivered to their workstation, or anyone in
	the organization can use telnet into the mailhost and
	user elm, pine, the old UCB mail, the RAND MH system
	or whatever.
<P> 
	All of these clients point their POP and mail clients
	to your mailhost.  Your host then acts as their spool.
	This is likely to result in fewer calls to your ISP and
	more efficient mail handling all around.
<P> 
	You may want to ask your ISP -- or look around -- for 
	UUCP providers.  On of the big benefits to this is that
	you gain complete control of mail addressing within your
	domain.  Typical UUCP rates go for about $50/mo for a 
	low volume account and about $100/mo for anything over
	100Mb per month.  However it's still possible to find
	bargains.
<P> 
	(Another nice thing about UUCP is that you can choose
	specific sites, with which you exchange a lot of mail,
	and configure your mail to be exchanged directly with
	them -- if they have the technical know-how at their
	end or are willing to let you do it for them.  This 
	can be done via direct dialup or over TCP connections).
<P> 
	uu.net is the Cadillac of UUCP providers (which is 
	a bit pricey for me -- I use a small local provider
	who gives me a suite of UUCP, PPP, shell, virtual hosting,
	virtual ftp, and other services -- and is of little
	interest to you unless you're in the Bay Area).
<P> 
	You can also find information on Yahoo! using
	a search for "uucp providers" (duh!).  I also 
	seem to recall that win.net used to provide 
	reasonable UUCP (and other) services.
<P> 
	Hope this helps.  If you need more specific help in 
	writing these scripts you may want to consider paying
	a consultant.  It should be less than three hours work
	for anyone whose qualified to do it (and not including
	the configuration of all your local clients).
<P> 
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="pseudo"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Pseudo Terminal Device Questions
</h3>
From: Jeong Sung Won
<P> <B> 
Hello ?<BR> 
My name is Jeong Sung Won. May I ask you a question ?
I'll make a program that uses PSEUDO TERMINAL DEVICE.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	No need to shout -- I've heard of them.  They're
	commonly called pty's -- used by 'telnetd', 'expect', 
	'typescript', and emacs' 'M-x shell' command -- among 
	others.
<P><B>  
<img align=bottom alt=" " src="../gx/ques.gif">
But linux has 8 bit MINOR NUMBER, so that total number of
pseudo terminal device DOESN'T OVERCOME 256.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	That does seem to be true -- but it is a rather
	obscure detail about he kernel's internals.
<P> 
	Linus' work on the 64-bit Alpha port may change
	this.
<P><B>
<img align=bottom alt=" " src="../gx/ques.gif">
Is there any possible way to OVERCOME THIS LIMITS ?
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	Only two that I can think of.  Both would 
	involve patching the kernel.
<P> 
	You might be able to instantiate multiple
	major devices -- which implement that same
	semantics as major device number 4 (the 
	current driver for the virtual consoles and 
	all of the pty's).
<P> 
	I'm frankly not enough of a kernel hacker to tell 
	you how to do this or what sorts of problems it would
	raise.
<P> 
	The other would involve a major overhaul of the
	kernel code and all the code that depends on it.
<P><B>  
<img align=bottom alt=" " src="../gx/ques.gif">
For example,on HP9000, minor number is 24 bit, 
and actually I used concurrently 800
pseudo terminal device. And more than 1000 is also possible.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	I wonder what it is on RS/6000, DEC OSF/1, and Sun/Solaris.
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
On Linux, is it impossible to make it, let me know the way I counld tell
LINUS that upgrade minor number scheme from 8-bit to 16-bit or more-bit 
is needed.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	Linus Torvald's e-mail address has been included with
	every copy of the sources ever distributed.  
<P> 
	However it is much better to post a message to the 
	comp.os.linux.development.system newsgroup than 
	directly to him (or any of other developer).
<P> 
	As for "telling LINUS [to] upgrade" -- while it would 
	probably be reasonably well recieved as a suggestion --
	I'm not sure that "telling" him what to do is appropriate.
<P> 
	It's easy to forget that Linus has done all of his work
	on the Linux kernel for free.  I'm not sure but I 
	imagine that the work he puts in just dealing with all the
	people involved with Linux is more time consuming and
	difficult than the actual coding.
<P> 
	As many of the people who are active in the Linux community
	are aware Linus has been very busy recently.  He's accepted
	a position with a small startup and will be moving
	to the San Francisco Bay Area (Silicon Valley, actually) 
	-- and he and Tove have just had a baby girl.  
<P> 
	I will personally understand if these events keep him 
	from being as active with Linux as he as been for the
	last few years.
<P> 
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="root"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
root login Bug in Linux
</h3>
<P> <B> 
From: Shevek, <A HREF="mailto:ma6ybm@bath.ac.uk">ma6ybm@bath.ac.uk </A> 
</B> <P><B>  
Has anybody else found a root login bug evident on my system.
</B> <P><B>  
The root password is an 8 character random series. For going live online 
I updated the root password to a 16 character random series. I can log in 
with the 16 character series, but also using the first eight and any 
random characters after that, or just the first eight. This creates an 
infinite number of root passwords and worries me more than a little.
</B> <P> 
About Unix Passwords and Security
<P>
	This is a documented and well known limitation of 
	conventional Unix login and authentication.
<P>
	You can overcome this limit if you upgrade to the 
	shadow password suite (replace all authenticating
	programs with the corresponding shadow equivalents)
	and enable the MD5 option (as opposed to the traditional
	DES hash).
<P>
	Note -- there is probably an "infinite" number of valid
	passwords to either of these schemes.  The password
	entry on your system is not encrypted.  That is a 
	common misconception.  What is stored on your system
	is a "hash" (a complex sort of checksum).  
<P>
	Specifically the traditional Unix DES hash uses your password as
	the key to encrypt a string of nulls.  DES is a one-way algorithm
	-- so there is no known *efficient* way to reclaim the key even
	if one has copies of the plaintext and the ciphertext.
<P>
	'Crack' and it's brethren find passwords by trying dictionaries
	of words and common word variations (reverse, replace certain
	letters with visually similar numerics, various abbreviations,
	prepending/appending one or two digits, etc) -- and using the
	crypt() function (or an equivalent) on a string of nul's to find
	matches.  This isn't particularly "efficient" -- but it is several
	orders of magnitude better than an exhaustive brute force attack.
<P>
	The only two defenses against 'Crack' are:  
<ol>
<li>		Don't let anyone have copies of the password hashes
		(which is why the shadow suite puts those in a separate
		file -- that is only readable by SUID or SGID programs,
		and not normal users)
<li>		Don't allow users to use words, names, or simple
		variations of words as their passwords.  This is don't
		by installing npasswd or passwd+ (replacements for the
		stock passwd program).
</ol>
	Use both of these strategies on all mult-user systems.
	That way, if someone exploits some newly discovered 
	bug to get a copy of the shadow file, he is less likely
	to get any good passwords (since that will entail a
	password that is more clever than your npasswd rules and
	less clever than your attackers custom 'crack' dictionaries).
<P>
	It is possible that two different passwords (keys) will
	result in the same hashed value (I don't know if there are
	any examples with DES 56 bit within the domain of all
	ASCII sequence  up to eight characters -- but it is possible).
<P>
	Using MD5 allows you to have passwords as long as you like.
	Again -- it is possible (quite likely, in fact) that a
	number of different inputs will hash to the same value.
	Probably you would be looking at strings of incomprehensible
	ASCII that were several thousand bytes long before you found
	any collisions.  
<P>
	Considering that the best supercomputers and parallel
	computer clusters that are even suspected to exist take
	days or weeks to exhaustively brute force a single DES
	hash (with a max of only 8 characters and only a 56-bit
	key) -- it is unlikely that anyone will manage to find 
	one of the "other" valid keys for any well chosen password
	without expending far more energy and computing time than
	most of our systems are worth.  (Even in these days of 
	cheap PC's -- computer time is a commodity with a 
	pricetag).
<P>
	There other ways to get long password support on your 
	system.  However the only reasonable one is to use the shadow
	suite compiled with the MD5 option.  This is the way that
	FreeBSD (and it's derivatives) are installed by default --
	so the code and systems have been reasonably well tested.
<P>
	In fact -- if security and robustness are more important
	to you than other features you may want to consider
	FreeBSD or (or NetBSD, or OpenBSD) as an alternative.
	These are freely distributed Unix implementations which 
	have been around as long as Linux.  Obviously they have a 
	much smaller user base.  However each has a tightly knit
	group of developers and a devoted following which provides
	or an extremely robust and well-tested system.
<P>
	As much as I like Linux -- I often recommend FreeBSD for
	dedicated web and ftp servers.  Linux is better suited to
	the desktop and to use with exotic hardware -- or in 
	situations where the machine needs to interact with
	Netware, NT and other types of systems.  
		[Oh, Oh!  Here come the fireballs!]
<P>
	FreeBSD has a much more conservative set of features 
	(no gpm support for one example -- IP packet filtering 
	is a separate package in FreeBSD while it's built into 
	the Linux kernel).
<P>
	Another consideration is the local expertise.
	Linux and FreeBSD are both extremely similar in most
	respects (as they both are to most other Unix 
	implementations).  In some ways they are more similar
	to one another than either is to any non-PC Unix.
	However the little administrative difference might 
	very well drive your sysadmin crazy.  Particularly if 
	he has a bunch of Linux machines and is used to them --
	and you specify one or two FreeBSD systems for 
	your "DMZ" (Internet exposed LAN segment).
<P>
	Back to your original question:
<P>
	You said that you are using a "random" string of characters
	for your password.  In terms of cryptography and security
	you should be quite careful of that word: "random"
<P>
	Several cryptographically strong systems have been 
	compromised over the years by attacking the randomizer
	that were used to generate keys.  A perfect example of
	this is the hack of SSL by a student in France (which 
	was published last spring).   He cracked a Netscape
	challenge and got a prize from them for the work
	(and Netscape implemented a better random seed generation
	algorithm).
<P>
	In the context of creating "strong" passwords (ones
	that won't be tested by the best crack dictionaries out
	there) you don't need to go completely overboard.  
	However -- if a specific attacker knows a little bit
	about how you generate your random keys -- he or she
	can generate a special dictionary tailored for that 
	method.
<P><B>  
<img align=bottom alt=" " src="../gx/ques.gif">
Kernel linux 2.0.20
System P90, 8Mb, IDE, SCSI (not working fully), cd, sound, etc.
root hda2, about 20 user entries in passwd.
</B> <P><B>  
Next bug:
Two users with consecutive login entries. Both simply information logins, 
never to be logged in to, just for fingering to for status information. 
If you finger the second, OK. But if you finger the first, it fingers 
both. UID numbers 25 and 26. If I comment 26, but have a third login on 
UID 27 then it is OK. I have tried unassigning the groups and reassigning 
them. They both have real home directories, shell is dev/null, and are in 
a group called 'private' on their own. There are no groups by the same 
name as the login.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	This sounds very odd.  I would want to look at the 
	exact passwd entries (less the password hashes) and to 
	know alot about the specific implementation of 'finger'
	that you were using (is it the GNU cfingerd?).
<P>
	I would suggest that you look at the GNU cfingerd.
	I think it's possible to configure it to do respond
	to "virtual" finger requests (i.e. you can configure
	cfingerd to respond to specific finger requests by 
	return specific files and program outputs without
	having any such accounts on your system).  This is 
	probably safer and easier than having a couple of 
	non-user psuedo accounts and using the traditional
	finger daemon.  (In additional the older fingerd is
	notoriously insecure and overflows of it was one 
	of the exploits used by the "Morris Internet Worm" 
	almost a decade ago).
<P>
	Given the concerns I would seriously consider 
	running a finger daemon in a chroot'd jail.
	Personally I disable this and most other services
	in the /etc/inetd.conf when ever I set up a new system.
<P>
	When I perform RASA (risk assessment and security auditing)
	/etc/inetd.conf is the second file I look at (after looking
	for a /etc/README file -- which no one but me ever keeps; and
	inspecting the /etc/passwd file).
<P>
-- Jim


<p><hr><p> 
<!--================================================================-->

<a name="again"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Sendmail-8.8.4 and Linux
</h3>
<P> <B> 
From: Brent Austin, <A
HREF="mailto:baustin@iAmerica.net">baustin@iAmerica.net </A>
</B> <P><B>  
After setting up fetchmail and the PPP link to my ISP, everything has worked
perfectly retrieving mail from the POP3 account.
</B> <P><B>  
Now, I've stumbled on another problem I require some help with.  Compiling
and Installing Sendmail-8.8.4 (or 8.8.5).  I downloaded the 8.8.4 source
from sunsite and set it up in the /usr/src directory and using the O'Reilly
"Sendmail" book as my guide, I modified the Makefile.Linux for no DNS
support by setting ENVDEF = -DNAMED_BIND=0. And removing Berkeley DB support
(removing -DNEWDB).
After compiling and executing ./sendmail -d0.1 -bt < /dev/null in the obj
dir, I receive the following:
</B> <PRE><B>  
Version 8.8.4
 Compiled with: LOG MATCHGECOS MIME7TO8 MIME8TO7 NDBM NETINET NETUNIX
		QUEUE SCANF SMTP XDEBUG
</B> </PRE> <B> 
and the program hangs at this point.
I am running Linux.2.0.29 on a 486DX40 with 8 megs.  My gcc is version 2.7.0.
</B> <P><B>  
Any hints you could provide are greatly appreciated!,
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	I fetched a copy of 8.8.5 and used the .../src/makesendmail
	script -- and only encountered the problems with NEWDB
	Removing that seemed to work just fine.
<P>
	I noticed you said -- .../src/obj -- did you mean something
	like: .../src/obj/obj.Linux.2.0.27.i386/
<P>
	If you properly used the makesendmail script then the
	resulting .o and binaries should have landed in a directory
	such as that.
<P>
	Other than that I don't know.
<P>
	I don't disable the DNS stuff -- despite the fact that
	my sendmail almost all done via uucp.  
<P>
	As for using this with fetchmail -- I have my sendmail
	configured in /etc/inetd.conf like so:
<PRE> 
# do not uncomment smtp unless you *really* know what you are doing.
# smtp is handled by the sendmail daemon now, not smtpd.  It does NOT
# run from here, it is started at boot time from /etc/rc.d/rc#.d.
## jtd:  But I *really do* know what I'm doing.
## jtd: I want fetchmail to handle mail transparently and I
## jtd want tcpd to enforce the local only restriction
smtp    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/local\
		/sbin/sendmail -bs
</PRE> 
	(note -- the line back is for this mail only -- remove it
	before attempting to use this line.  Also note the -bs
	"be an smtp handler on stdin/stdout")
<P>
	This arrangement allows me to fetchmail, lets fetchmail
	transparently talk to sendmail, and keeps the rest of the
	world from testing their latest remote sendmail exploit
	on me while my ppp link is up (I wouldn't recommend this
	for high volume mail server!).
<P>
	Naturally I also have a cron job like this:
<PRE> 
## Call sendmail -q every half hour
00,30 * * * * root /usr/lib/sendmail -q
</PRE> 
	(which processes any mail that elm, pine, mh-e
	or any other mailers have left in the local queue --
	awaiting their trip through uucp's rmail out to the
	rest of the world).
<P>
	If you continue to have trouble compiling sendmail
	then you may want to just rely on the RPM updates.
	Compiling it can be tricky, so I avoid doing it 
	unless I see a bugtraq or CERT advisory with the
	phrase "remotely exploitable" in it.
<P>
	Re: O'Reilly's "bat" book.  Do you have the 2nd Edition?
	If not -- get it (and ask them about their "upgrade"
	pricing/discount if that's still available)
<P>
-- Jim
<p><hr><p> 
<!--================================================================-->

<a name="wuftpd"></a>
<h3> <img align=bottom alt=" " src="../gx/ques.gif">
wu-ftpd Problems
</h3>
<P> <B> 
From: Ed Stone, <A HREF="mailto:estone@synernet.com">estone@synernet.com </A>
</B> <P><B>  
On BSDI, I've read ALL of the doc for wu-ftpd, and have ftp logins
limited to the chroot dir, but still have these problems:
1) I cannot force ftp only. The guestgroup "guests" can telnet, and go
everywhere. I've put /bin/true in /etc/shells; I've edited passwd and
master.passwd for that; no effect
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	Usually I set their passwd to /bin/false or /usr/bin/passwd.
	I make sure that I use the path filter alias to prevent
	uploads of .rhosts and .forward files into their 
	home directory under the chroot and I put entries like:
<PRE> 
		/home/.ftp/./home/fred
</PRE> 
	... for their home directory field in the (true-root)/etc/passwd
	file.
<P>
	Also make sure that you have the -a switch on the ftpd 
	(or in.ftpd) line in your inetd.conf.  The -a tells ftpd to
	use the /etc/ftpaccess file (or /usr/local/etc/ftpaccess --
	depending on how you compiled it).
<P>
	Personally I also configure each "ftponly" account into
	the sendmail aliases file -- to insure that mail gets
	properly bounced.  I either set it to the user's "real"
	e-mail address (anywhere *off* of that machine) or I set it
	to point at nobody's procmail script (which autoresponds to
	it).
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
2) "guests" ftp to the proper directory, but get no listing. I have set
up executable of ls in the ftp chroot dir in /bin there; no effect.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	How do you know that they are in the proper directory?
	What happens if you use a chroot (8) command to go to 
	that dir and try it?  Is this 'ls' statically linked?
	Do you have a /dev/zero set up under your (chroot)/?
<P>
	Most common cause of this situation is a incomplete 
	(chroot) environment -- usually missing libraries or 
	missing device nodes.
<P>
-- Jim
<P>

<!--================================================================-->
<P> <hr> <P> 
<center><H5>Copyright &copy; 1997, James T. Dennis <BR> 
Published in Issue 15 of the Linux Gazette March 1997</H5></center>

<P> <hr> <P> 
<!--================================================================-->
<A HREF="./lg_toc15.html"><IMG SRC="../gx/indexnew.gif" ALT="[ TABLE OF 
CONTENTS ]"></A> <A HREF="../index.html"><IMG SRC="../gx/homenew.gif" 
ALT="[ FRONT PAGE ]"></A> 
<A HREF="lg_bytes15.html"><IMG SRC="../gx/back2.gif" ALT=" Back "></A>
<A HREF="./clueless.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
</body> 
</html>