Future: fhs 2.3 compliance for fc3

Stephen Smoogen smoogen at lanl.gov
Fri Apr 2 19:23:16 UTC 2004


On Fri, 2 Apr 2004, Havoc Pennington wrote:

>On Thu, 2004-04-01 at 20:52, Chris Adams wrote:
>> Once upon a time, Jeremy Katz <katzj at redhat.com> said:
>> > Heh, that's just sick.  How about my statement holding for when the
>> > clients are set up correctly? :-)  (ie, if you don't use local sendmail
>> > and just do smtp, then local /var/spool isn't needed)
>> 
>> Way too many programs expect to be able to call /usr/sbin/sendmail to
>> assume everything will use SMTP.  And really, that is how it should be;
>> why should every program be required to have an SMTP client built-in?
>> 
>> The nice thing about that is that you are pretty much guaranteed that
>> you can send mail at any time, even if the network is down.  Sendmail
>> (or another local mailer) will queue the mail locally and send it when
>> it can.  It is not a good idea to have things like cron jobs get stuck
>> or lose their output because a remote SMTP server was unreachable.
>
>I think we have to assume that a managed read-only OS image sort of
>deployment would have some limitations in possible configurations and
>what apps could do. After all the whole point is to lock things down.
>
>One setup would be that each user has an outgoing mail queue in their
>home directory, since homedir already has to be writeable by the user
>and gets backed up and so forth. Surely you could provide a
>/usr/sbin/sendmail that worked this way.
>
>A queue in /var is suboptimal because it partially defeats the purpose
>of the deployment model - it leaves per-machine state to be corrupted,
>backed up, hacked, etc.
>

How is printing done? How do cron jobs mail when a services home 
directory may not exist and the shell is nologin? Not trying to poke 
holes as much as think things out-loud. I wonder if queues should go 
under /var at all?


-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --





More information about the fedora-devel-list mailing list