Sealed Server

Matthew Seaman m.seaman at
Sat Nov 17 12:13:07 PST 2007

Hash: SHA256

jekillen wrote:
> Hello;
> I am planning on setting up Cyrus on a machine
> and the documentation says that it is intended'
> for use on 'sealed' servers (servers for which there
> are no accounts that can log into the system)

This is really just trying to say that you don't need
a Unix login account in order to have an e-mail account
via Cyrus IMAPd.

Of course any server will require user accounts for its
administrators to be able to log in.

> However:
> If I use ssh to administer the system, I have to
> set it up so I can ssh directly to root, right.

Wrong. The best practice is to require users to log in
as themselves (thus establishing some sort of audit trail)
and then use some program like su or sudo to gain rootly
powers.  At work we use a second instance of sshd bound to
a high-numbered port on the loopback so you can ssh to root
only after you've logged in and only if you've using
ssh-agent and your ssh public key is in root's
..ssh/authorized_keys file.

> and
> Since there are references to use of MySQL
> and the MySQL user is set up as a normal
> user with a login/pwrd,

No -- mysql runs as a non-privileged user which doesn't need
to have any password set or any ability for anyone to get a
login session as the mysql user.  All that ID is for is to own
some files and the various mysqld processes.  This is a standard
practice with most long-running daemons exposed to the network:
it limits the damage that can be done by remote compromise of
the software.

> How do I get around that? (have MySQL
> running on a different machine, or something?)

Unless you're running a particularly heavyweight Cyrus
installation (ie. lots of users + lots of e-mail) or you've 
got really weedy hardware, then you're better off running 
MySQL on the same machine as the rest of the mail system.

Remember that there is a completely separate set of logins
and passwords *within* MySQL -- nothing to do with the system
logins from /etc/passwd.

The best way to configure MySQL in that situation is to

    * use 'skip-networking' in the configuration file.  This
      forces all connections to mysql to be via the unix domain
      socket in /tmp/mysql.sock

    * Run 'mysql_secure_installation' to remove remote root access,
      set the root password, get rid of wildcarded logins etc.

    * Review all user IDs and GRANTS carefully -- if you aren't using
      networking, then all your MySQL users should be
      'userid'@'localhost' Adopt a polict of *minimum privilege* --
      allow only the necessary access required for things to keep

    * In order to prevent the MySQL root password being used routinely
      (which makes it far more likely to be disclosed), create a 
      file /root/.my.cnf with contents like:

user = root
password = yourpassword

      Make sure the file is mode 600: read-write only for the owner
      With this in place, then once you've become the Unix root user
      you can then just type 'mysql' and get a root MySQL session
      without having to type any passwords.  ie. you rely on the
      security of your Unix root account to protect your MySQL
      root account.

> Please forgive my lack of sophistication on this
> issue, I am learning.
> (I have also been looking at Dovecot)
> I have assembled some documentation on this
> but have not found a direct answer, thus the
> query here.
> system uses Postfix on FreeBSD 6.2

Dovecot is good, and its configuration -- particularly where stuff like SASL
is concerned -- is a lot easier for inexperienced users.  It will run a mail
server for tens of hundreds of users perfectly satisfactorily.  On the other
hand, if you're looking at thousands of users then Cyrus IMAPd is what you

> One FYI that may be of interest:
> I had my own dns servers listed in
> resolv.conf before the isp's dns servers
> and messages sent from this machine
> (FreeBSD w/Postfix) were failing to deliver
>  to jekillen at due to dns lookup failures.
> So I changed the order in resolv.conf (listing isp dns
> servers first) and the messages were then delivered.
> I  thought that if one server could not respond with
> enough info, the next server would be tried until one
> was successful (making order insignificant).

Sounds like your own recursive DNSes weren't actually working.
Flaky DNS is the cause of most of the delays or failures that
spoil your user experience: until you've thoroughly mastered managing
DNS servers, I'd recommend using your ISPs servers.  Having
reliable DNS will help you a great deal while you are debugging
your mail server setup.



- -- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP:     Ramsgate
                                                  Kent, CT11 9PW
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla -


More information about the freebsd-questions mailing list