Original questions are the ones below namely:
>1.) Anybody successfully installed procmail to run under Alpha Digital UNIX?
Almost all of the respondents confirmed that they have successfully
installed such a software on their system.
A recent version can be picked up at various comp.sources.misc archives.
The latest version can be obtained from your friendly neighbour mirror site:
ftp://ftp.aist-nara.ac.jp/pub/misc/mail/filters/procmail
ftp://ftp.net.ohio-state.edu/pub/networking/mail/procmail
ftp://ftp.psg.com/pub/unix/procmail
ftp://hub.ucsb.edu/pub/mail (hand updated)
ftp://ftp.tamu.edu/pub/Unix/Mail (hand updated)
Or directly as:
ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail/procmail.tar.gz
>2.) What might be the implications and preparations that might be done
>before enabling the enhanced security feature of an Alpha?
Enhanced security (from their comments) did not affect procmail at all.
Michael Matthews says:
----------------------
I turned on enhanced security and it did not affect procmail at all.
You might wanna worry about the implications of procmail itself -- sendmail
can be spoofed and if your .procmailrc file is insecure that can be used to
exploit your system in theory.
Spider Boardman comments:
------------------------
Well, first of all, which version of Digital UNIX are you running? It
matters as to the answer. For V3.2 with patches from the Customer Support
Centre, or V3.2C (optionally with Support Centre patches), however, I
would recommend (1) being reasonably sure you know where to find things in
the "Security" book that ships with the product, since many things are
only explained there, and (2) back up your /etc/group and /etc/passwd
files before you run the secsetup utility.
Another (optional) step is to familiarise yourself with the administrative
interfaces (XSysAdmin and XIsso) before making the switch. As long as the
OSFC2SECnnn and OSFXC2SECnnn subsets are installed (as reported by 'setld
-i'), you can use those utilities to manipulate the enhanced security
databases even before you've switched to using that package.
Jon Buchanan gives the details:
------------------------------
Enhanced Security by itself shouldn't be difficult to set up. What is
more complicated is NIS with Enhanced Security, which we struggled for
months to get working under OSF/1 3.0, receiving many patches from DEC.
We eventually got it to work and I would expect that the patches have
been incorporated into OSF/1 3.2 (at least 3.2A, certianly 3.2C).
Here are some tips and notes:
With enhanced security, your user, group and password databases are
divided into many places:
/etc/passwd
This contains entries for local users not defined under NIS.
Passwords are not stored here - a * appears in place of each password.
Typically you would leave the system users like root, deamon etc here.
NIS-defined users must not appear in this file!
At the end of this file is +: for NIS to be searched.
/tcb/files/auth directories
Users defined in /etc/passwd have security profiles in these
directories. Their passwords, and things like successful/unsuccessful
login info are stored here. No NIS users have profiles in these
directories.
/etc/group
This contains entries for local groups not defined under NIS.
At the end of this file is +:
/var/yp/src/passwd
This is your NIS passwd file.
Local users, defined in /etc/passwd, should NOT appear here!
Passwords are not stored here - a * appears in place of each password.
The file should not contain +:
/var/yp/src/prpasswd
This is the 'protected password' NIS file, which functions like the
/tcb directory but for NIS users instead of local users. All users
with an entry in the NIS password file have an entry here.
/var/yp/src/group
This is the NIS group file.
Local groups, defined in /etc/group, should NOT appear here!
The file should not contain +:
Creating the prpasswd file is described in the section 'Moving Local
Accounts to NIS' which is Appendix C of the 'Security' manual. You have
to copy the script they give you in the book, which reads all the
information from the /tcb tree and writes it into a file with one line
per user. After that you need to:
- delete (or move) all security profiles below /tcb for NIS registered
users
- delete all prpasswd entries for locally registered users (like root)
this is in accordance with the split described above.
When you are using the advanced security XIsso and XSysAdmin tools you
choose whether to manage the local or NIS registered users by clicking
on the 'Network Control' button. It then updates only the appropriate
files, and in the case of the NIS files, does a make for you.
To change passwords, use passwd for all accounts including the NIS ones.
Delete the files /etc/passwd.dir and passwd.pag if you have them. These
are 'hashed' password files which adduser offers to make for you when it
finds they are not there. However, you don't need them and it will
probably stop NIS from working properly.
The main problem with switching Enhanced Security/NIS on and off is in
restoring the information to the correct place. Above all, Enhanced
Security passwords CANNOT be re-inserted into the passwd files (in place
of the *'s) - you need to give all users a new password.
A couple of problems that took us a long time to solve:
- The file /etc/auth/system/files must contain entries for
prpasswd and prpasswd:t. We have added them like this:
/var/yp/src/prpasswd:\
:f_type=r:f_mode#0660:f_owner=auth:f_group=auth:\
:chkent:
/var/yp/src/prpasswd\:t:\
:f_type=r:f_mode#0660:f_owner=auth:f_group=auth:\
:chkent:
- An Enhanced Security NIS Slave cannot operate independently of the
Enhanced Security NIS Master. This is because the prpasswd file
is updated with every login attempt, and is only mastered on the
NIS Master. In other words, there's no point having a Slave because
it won't be able to function without the Master running.
DEC have refused to acknowledge this as a problem, so a fix is
unlikely for the forseeable future. We have worked around it by
setting up a second Master and copying certain files from the
'real' master to the 'second' master periodically using rdist.
It is not an altogether satisfactory solution but it works and we
prefer it to being dependent on the availability of one machine.
Let me know if you would like more details on setting this up.
If you are determined to set up a Slave then you may hit another problem
too, whereby a make of the yp maps pauses for a few minutes. Fix is to
send the Slave the copies of the maps which it is missing by using ypxfr
(but a better fix is to disable the Slave).
One other note about Enhanced Security - if your system manages X
sessions for X displays (such as PCs) then you will need to add entries
for these remote displays to the files /etc/auth/system/devassign and
/etc/auth/system/ttys.
Many thanks to the responders namely:
Michael Matthews <matthewm_at_sgate.com
Julyan Cartwright <julyan_at_hp1.uib.es>
Tim Mooney <mooney_at_dogbert.cc.ndsu.NoDak.edu>
Spider Boardman <spider_at_orb.nashua.nh.us>
Jon Buchanan <Jonathan.Buchanan_at_ska.com>
Simon Greaves <censjg_at_caledonia.hw.ac.uk>
Bonn
:)
Received on Sat Feb 03 1996 - 21:23:03 NZDT