Thank you, Risto, we could try to integrate lcall with calendar into our
setup. SELinux was just theoretical example, we have no problem with that
now, I was just seeking for bullet-proof solution.
Richard
st 8. 4. 2020 o 12:05 Risto Vaarandi <risto.vaara...@gmail.com> napísal(a):
> hi Richard,
>
> if you want to find input files which can not be opened because of
> permission issues, and want to conduct all checks specifically from SEC
> process without forking anything, I would recommend to set up an 'lcall'
> action that runs all checks from a Perl function. Since this function is
> executed within SEC process, it will have the same permissions for
> accessing the file as SEC itself. If you return one or more values from the
> function, 'lcall' will set the output variable by joining return values
> into single string, so that newline is acting as a separator between return
> values. Also, if no values are returned from the function, output variable
> will be set to perl 'undef'. After collecting the output from the function
> in this way, you can provide the output variable to 'event' action that
> creates synthetic event from its content. Note that if multi-line string is
> submitted to 'event' action, several synthetic events are generated (one
> for each line). And now that you have synthetic events about files that are
> not accessible, you can process them further in any way you like (e.g., an
> e-mail could be sent to admin about input file with wrong permissions).
>
> Here is an example rule that executes the input file check once a minute
> from Calendar rule:
>
> type=Calendar
> time=* * * * *
> desc=check files
> action=lcall %events -> ( sub { my(@files, @list, $file); \
> @files = glob("*.log"); foreach $file (@files) { \
> if (!open(FILE, $file)) { push @list, "$file is not accessible";
> } else { close(FILE); } \
> } return @list; } ); \
> if %events ( event %events )
>
> The action list of the Calendar rule consists of two actions -- the
> 'lcall' action and 'if' action, with 'if' action executing 'event' action
> conditionally. The 'lcall' action tries to open given input files and
> verify that each open succeeds. For all files that it could not open,
> 'lcall' returns a list of messages "<file> is not accessible", and the list
> is assigned to %events variable as a multi-line string (each line in the
> multi-line string represents one message for some file). If the list is
> empty, %events variable is set to perl 'undef' value. After 'lcall' action,
> the 'if' action is executed which verifies that %events is true in perl
> boolean context (if %events has been previously set to 'undef', that check
> will fail). If the check succeeds (in other words, we have some messages to
> report), the 'event' action will generate synthetic events from messages.
>
> That is one way how to check input files without forking anything from
> SEC. However, if the root cause of the problem is related to SELinux, it is
> probably much better to adjust SELinux configuration (perhaps by changing
> file contexts), so that the problem would not appear.
>
> kind regards,
> risto
>
>
> Kontakt Richard Ostrochovský (<richard.ostrochov...@gmail.com>) kirjutas
> kuupäeval E, 6. aprill 2020 kell 17:21:
>
>> Hello friends,
>>
>> I am thinking about how to monitor not only events from log files, but
>> also those files existence and accessibility (for user running SEC) - in
>> cases, where this is considered to be a problem.
>>
>> As I saw in the past, these were logged into SEC log file, but higher
>> debug level was required, so it is not suitable for production.
>>
>> There are handful of other options how to monitor it "externally", e.g.
>> via some script, or other monitoring agent, but this is not ultimate
>> solution, as e.g. SELinux may be configured, allowing external script or
>> agent (running under the same user as SEC) to see nad open file for
>> reading, but not SEC (theoretical caveat of such solution).
>>
>> So, has somebody some "best practise" for reliable and production-ready
>> way, how to "self-monitor" log files being accessed by SEC, if:
>>
>> - they exist
>> - they are accessible by SEC
>>
>> ?
>>
>> Thanks in advance.
>>
>> Richard
>> _______________________________________________
>> Simple-evcorr-users mailing list
>> Simple-evcorr-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>>
>
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
