[Mageia-dev] [RFC] msec (nail) can't send reports to local users accounts - require an MTA?

Florian Hubold doktor5000 at arcor.de
Fri Sep 23 11:05:03 CEST 2011

Am 23.09.2011 10:47, schrieb Florian Hubold:
> Am 22.09.2011 23:11, schrieb andre999:
>> Florian Hubold a écrit :
>>> Am 22.09.2011 00:09, schrieb Luc Menut:
>>>> Le 21/09/2011 20:35, Florian Hubold a écrit :
>>>>> Hello,
>>>>> during validation of validation of msec/sectool update candidates,
>>>>> a problem showed up: https://bugs.mageia.org/show_bug.cgi?id=1621
>>>> ...
>>>>> But if we want security reports to be sent to local users if they
>>>>> specify so, how to proceed further?
>>>> msec can work very well without sending these reports by email; all
>>>> the security's reports are available in /var/log/security, and msec
>>>> notifies the user about this at each time it runs, so sendmail is
>>>> absolutely not mandatory.
>>>> So I think that msec shouldn't have a Requires on sendmail-command,
>>>> eventually it can be a Suggest.
>>>> But perhaps we could/should change the configuration of msec to not
>>>> send email by default, by adding MAIL_WARN=no in
>>>> /etc/security/msec/security.conf.
>>> So, to summarize, there happen to be multiple solutions here:
>>> 1. do NOT require an MTA, let users manually read reports from
>>> /var/log/security
>>> maybe even remove nail from msec Requires as it is currently
>>> non-functional.
>> Reading from /var/log/security is not especially user-friendly, and will be 
>> ignored by less savy users.
> Less savvy users might also not want to read security reports, also it would 
> mean they
> can't interpret them properly or fix the cause of reported problems, no?
>>> Also Luc's proposal cited above could be realized.
>> see below.
>>> 2. do require sendmail-command, which will pose a problem to users
>>> installing from the CLI, because they are presented with a choice:
>>> One of the following packages is required:
>>> 1 dma
>>> 2 ssmtp
>>> 3 postfix
>>> 4 sendmail
>>> 5 msmtp
>>> Please make a selection:
>>> Additionally this will force an MTA onto every default installation and
>>> every
>>> installation that currently has msec installed.
>> Solution 3 avoids the complication of choosing, with virtually no disadvantage.
>>> 3. do require dma, which is a rather minimal MTA, and delivers without
>>> configuration
>>> Please see https://bugs.mageia.org/show_bug.cgi?id=2255#c36 for details.
>>> This would also allow coexistence with an already-installed MTA, IIUC.
>> (dragonfly mail agent)
>> If this works, I'd say that it is the best solution, since it is very 
>> compact (64k), and virtually every system will have the DNS it requires 
>> installed.
>> (Unless of course they don't have Internet or network access.  In which case 
>> msec would not be particularly important.)
>> Note that it is only at version 0.2 (or 0.3 upstream), so we should test it 
>> carefully.
>>> 4. Try to fix nail, which is required by msec and so in every default
>>> installation,
>>> so that it is able to deliver mail by itself, without sendmail.
>> Solution #3 seems much better in every respect.
>>> Please give your votes.
>> Solution 3, with changes/verifications noted below.
>> Since it is much simpler for the end-user to always have the capability to 
>> send security alerts if an email address is entered, without installing 
>> anything extra.
>> There are 2 options at the bottom of the first security page of msec, which 
>> should already realise Luc's proposals.  They may have to be fixed.
>> a) An option to send a security alert by email, where one enters the email 
>> address.  By default it is checked.
>> However, if no valid format email address is entered, an email should _not_ 
>> be sent.
>> As well, we should display something similar to
>> "(Enter {userid}@localhost for a local user.)",
>>  to help ensure that the user enters a valid local address.
>> (Note that there are multi-line descriptions for all the other options above 
>> on the same page, so this would fit nicely.)
>> b) An option to display security alerts on the desktop.  Again, checked by 
>> default.  They should probably remain visible until the user dismisses them. 
>> (They currently display for a few seconds, then disappear.)
Correction: If you mean a notification popup which tells you that the report 
can be looked
up at /path/to/report is already in place, aus Eugeni told already.
>> My 2 cents :)
> Feel free to send patches for a) and b).

More information about the Mageia-dev mailing list