[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /etc/passwd doesnt contain all users

Brian May <bam@debian.org> [2003-01-01 10:27:36 +1100]:
> On Tue, Dec 31, 2002 at 02:37:55AM -0700, Bob Proulx wrote:
> > Yet another, "Excuse me?"  When would any sendmail files ever be
> > shared?  That does not fit any workable model in my head.  Being local
> > to the machine the local uid will override the NIS uid and everything
> > works fine.  Or if adduser detects the NIS uid it won't add a local
> > one and therefore you will get the NIS one.
> Diskless NFS systems with no local harddisk, where all directories are
> stored on a server.

When I am thinking of mail and spool directories I am thinking of two
different directories.  /var/spool/ which hosts the systems mail queue
and /var/mail/ which hosts the user end delivery mailboxes.  I say
this just to keep us on the same track.  The /var/spool area would
hold system uids.  The /var/mail area would hold non-system uids.

There have been many schemes in the historical record to share
/var/mail across NFS.  Usually so that diskless clients can allow
non-system users to read their mail by accessing /var/mail in the
normal way as if it were a local filesystem.  That has had different
degrees of success depending upon many things.

The local mail client MUA needs to know nothing.  Except that if they
really don't know it is over NFS then locking is problematic.  Most
people stick their head in the sand and ignore the problem and claim
ignorance when a user complains about random mailbox corruption.
Procmail specifically deals with it directly.  Probably a better
answer in that case is to support IMAP to the mail server.  That
avoids the problem of NFS mailboxes entirely.  It avoids some NFS
issues in general.

> No, I don't know if storing sendmail queues on NFS is a good idea, it
> probably isn't; another package might be more appropriate.

A diskless mail server that uses an NFS /var/spool directory.  Please
spare me that sight!  I am sure someone will post the need to use a
NFS network appliance for all disk purposes.  It does not mean I have
to like it.  That would not be my idea of a highly available, high
performance mail server.

In the case of an NFS mounted /var/spool for an individual host and
not shared with any other host things should work regardless of uid
overlap.  It would be confusing perhaps.  Security is always an issue
but if you operate in a locked room lan perhaps not germane for for
that implementation.  But as long as the uids are consistent between
each host and its associated /var/spool directory then different hosts
can have different 'maildrop' ids in different NFS non-shared
directories and it would be fine.

> No, the directories aren't "shared", but you don't want UIDs to
> be different on the client and the server, not only could it create
> security issues, but also cause much confusion too.

Agreed.  But if this is the case then the admin is definitely
operating in a very special case situation and would need to handle
the special case needs on their own.  It should not be a recommended
case.  It is certainly fraught with subtle problems.  It is clearly
dependent upon the particular mail software running in that shared
directory.  I don't think Debian needs to go to extreme measures to
support it, just to allow it.  The paradigm of easy things being easy
and hard things being possible.

I don't know of any MTA that is written with the idea that it will
operate with multiple hosts sharing a /var/spool directory.  It is
certainly possible that someone will write one or adapt one.  I would
not recommend it, however.

> This also raises a number of other issues like "should postfix running
> on the server really be able to access the spool directory of each of
> NFS client?", but I don't want to get into that right now; SE-Linux
> might be the complete answer, eg. only allow the NFS server process
> access to these files on the server.

[The words used here lead me to believe you are suggesting a central
mail server writing to /var/mail on the remote clients.]  That is a
new twist on things.  In that case wouldn't using the MTA to MTA
protocol be safer?


Attachment: pgpzx_crdquJO.pgp
Description: PGP signature

Reply to: