On Sat, 21 Jul 2001 18:57:46 -0700 Ken Moffat wrote:
>
> I'd like to know the differences I can expect to encounter if I go from
> eD2.4 to RH7.1. There are probably many subtle differences, and I
> thought someone might have some thoughts?
> Got 3 cd's in the RHL7.1 Bible. Popped one in and it wants to install
> right away, fired up X immediately.
> Thanks for any info....
I just did this a few months ago. Now I'm trying to move from RH 7.1 to
Caldera 3.1.
RH has it's nice points, teh new KDE for example. However, perl is broken,
gcc has probnlms, and I have some nagging problems I don't understand that
I hope will go away when I get Caldera running.
The thing I hate is that they don't use /usr/local like everyone else. Or
/opt. Makes it harder to segregate executables onto other disk partitions
and generally manage stuff.
And the new sendmail caused me lots of grief - if you use .forward be prepared
for trouble. Here are my notes from when I worked through it ...
------
Trying to adapt my .forward file mail filtering to Redhat 7.1 and
sendmail 8.9.
It wasn't working, and when I looked in the mail spool
/var/spool/mqueue
and read the messages stuck there I saw stuff like :
smrsh: cannot use > in command
and errors (that I forgot to save) that my userid was not safe for frowarding
or something like that. Here's what I did to hack around it. Note that this invo
lves
subverting the security features of sendmail. I am doing this on a single-user b
ox, so
I feel justified. But be careful!
----
Added to /etc/mail/sendmail.mc
define(`confDontBlameSendmail',`forwardfileinunsafedirpath,forwardfileinunsafedi
rpathsafe')dnl
and added to
/etc/mail/trusted-users
ajackson
and added to
/etc/smrsh
ln -s /home/ajackson/filter filter
----
To recompile sendmail
m4 /etc/mail/sendmail.mc > /etc/sendmail.cf
/etc/rc.d/init.d/sendmail restart
*Then*, I copied /home/ajackson/filter to ~/realfilter and in filter put :
------
#!/bin/sh
cat - | exec /home/ajackson/realfilter >> /home/ajackson/.bak 2>&1
------
so I could use the file redirection. Sigh.
References :
man sendmail
man smrsh
http://www.sendmail.org/tips/DontBlameSendmail.html
/usr/share/sendmail-cf/README
Extracts from documents :
Beginning with sendmail 8.9, these checks have become more strict to prevent
users from being able to access files they would normally not be able to read.
In particular, .forward and :include: files in unsafe directory paths
(directory paths which are group or world writable) will no longer be allowed.
This would mean that if user joe's home directory was writable by group staff,
sendmail would not use his .forward file. This behavior can be altered, at the
expense of system security, by setting the DontBlameSendmail option. For
example, to allow .forward files in group writable directories:
O DontBlameSendmail=forwardfileingroupwritabledirpath
Or to allow them in both group and world writable directories:
O DontBlameSendmail=forwardfileinunsafedirpath
Items from these unsafe .forward and :include: files will be marked as unsafe
addresses -- the items can not be deliveries to files or programs. This
behavior can also be altered via DontBlameSendmail:
O DontBlameSendmail=forwardfileinunsafedirpath,
forwardfileinunsafedirpathsafe
The first flag allows the .forward file to be read, the second allows the
items in the file to be marked as safe for file and program delivery.
If you have an unsafe configuration of .forward and :include: files, you can
make it safe by finding all such files, and doing a "chmod go-w $FILE" on each.
Also, do a "chmod go-w $DIR" for each directory in the file's path.
------------------
Starting in 8.6.5, sendmail added a security check; from the RELEASE_NOTES:
If a user had an NFS mounted home directory on a system with a
restricted shell listed in their /etc/passwd entry, they could
still execute any program by putting that in their .forward file.
This fix prevents that by insisting that their shell appear in
/etc/shells before allowing a .forward to execute a program or
write a file.
Though the SMI-8.6 version is based on 8.6.10, this feature was disabled.
There are two easy work-arounds to this problem: Add the entry
/SENDMAIL/ANY/SHELL/ on a line by itself in /etc/shells. This will allow all
shells; however, this solution is not recommended. A Bourne-shell script,
gen-etc-shells.sh, is available. It lists the 10 built-in shells allowed by
getusershell(3C). It then uses getent(1M) to extract all passwd entries; these
are piped to an awk script which extracts the shell information. Once this is
cleaned up and some known bogus entries are stripped out, the resulting output
is appropriate for creating a new /etc/shells file, which will allow exactly
the shells that were allowed previously, but no others.
--
-----------------------------------------------------------------------
| Alan K. Jackson | To see a World in a Grain of Sand |
| [EMAIL PROTECTED] | And a Heaven in a Wild Flower, |
| www.ajackson.org | Hold Infinity in the palm of your hand |
| Houston, Texas | And Eternity in an hour. - Blake |
-----------------------------------------------------------------------
_______________________________________________
http://linux.nf -- [EMAIL PROTECTED]
Archives, Subscribe, Unsubscribe, Digest, Etc
->http://linux.nf/mailman/listinfo/linux-users
