Bug#367337: [Pkg-aide-maintainers] Bug#367337: /var/run/aide.lock breaks non-root use of aide

[Bob Proulx]

Marc Haber wrote:
> How about using $HOME/.aide.lock if the wrapper is not invoked as root?

But what if a user wants to run aide on two unrelated databases and
wishes to do this simultaneously?  That would be a problem.

If the concern really is two aide processes writing to the database
output file then the semaphore needs to be on the database output file
itself and not in other places.  Anything else causes other issues.
But that means extracting the output file from the config file.  But
that should work.

> > I suggest also using a lockfile only if no --config is given by the
> > user.
> 
> Bad idea, IMO. aide can run for a considerable period of time, and two
> aide processes operating on the same database guarantee database
> breakage.

I probably missed a bug report on this previously.  Is this really a
concern?  I mean, 'cp srcfile dstfile' could be a long operation.  If
I run two of those commands at the same time then dstfile would be
"corrupted".  But does that mean that cp needs to use a semaphore when
copying files?

I know that aide can run for a long time.  (I think it might be
infinitely long with the latest version.  Still working to verify
that.)  But I do not believe it is the package's job to protect me
from myself.  It is only the package's job to protect scripts provided
by the package from itself.

> > Also, printing a message when a user is using --config is not
> > expected.  I would like to see the message removed.
> 
> I am not going to do this, since running aide without protection of a
> lock poses a significant risk to the database.

But this means that Debian users will just need to know that they
really need to call aide.real instead of aide as on other systems.
Behavior is diverging from expected upstream behavior.  It needlessly
diverges from other distros.  I think that is bad.

> > And passing raw arguments to echo can
> > open up possibility of problems there.
> 
> I don't see any arguments passed to echo in the aide wrapper. Where do
> you see that?

The original script had:

  if echo $@ | grep -q -- '--config[^-]'; then

But $@ can be any arbitrary string passed into the command by a user
calling it.  (In that context, unquoted, $@ is the same as $*.)  A
user may have passed in options which may look like an option to echo.
And since echo is one of the most frustratingly importable commands
different shells may interpret echo options differently and this may
confuse echo.  At the least bash supports the -n, -e, and -E options.
I was attempting to avoid trouble there by using printf which is
standardized.

As an aside, I did not understand why "[^-]" was there.  The --config
was the only valid option string that could match there.

> > I am not quite happy with the grep test for a --config option because
> > it ignores the -c possibility.  But without doing a full getopts
> > parsing it is difficult to get this completely correct.
> 
> Agreed. I'd appreciate a patch anyway.

A patch in which direction?  Implementing a full getopt parsing
mirroring available aide options?  Or one that only looked for
--config?  I am not quite tracking.  (I could easily write a script
using getopt that parsed all of the options the same as aide the
program implemented.)

I hate replicating all of the options in getopt because then the
script would need to track the program closely forever after that.  It
would violate the DRY (don't repeat yourself) principle and create a
maintenance issue.  But it does generate the most correct result for
any given moment in time.  But avoiding the need to track the program
options is why I would go with only looking for --config.  It is a
reasonable compromise.

Different direction...

I am thinking that there are two different things that are trying to
be accomplished at the same time.  One is that when a user installs
aide on the system it is desirable to set up a system level task that
aide will run mostly by default with minimum user configuration.  That
is good.  The other is that aide is a general purpose program run by
users to check files.  (Web pages in my case.)  At this time the
implementation of these two tasks are tripping over each other.

To accomplish a modular config file (a noble cause) a wrapper was
implemented to build the configuration file on the fly from the
pieces.  The real binary was moved to aide.real.  This all works for
the system scripts provided with the package.  But this gets in the
way of non-system users using aide for tasks outside of the
prepackaged scripts.  Because the /usr/bin/aide script has had several
issues that make it suitable only to be called by the root process
system script from the package.  That seems like a restriction that we
should avoid if possible.

This is leading me to believe that the current package is not going
the right direction.  I think it should go a different direction.
Previously the aide program was renamed to aide.real so that
/etc/cron.daily/aide could call it "aide".  But 'aide' the program is
not the sole domain of /etc/cron.daily/aide and that is causing me
problems.  Instead I am thinking that the binary should not be renamed
nor wrapped with a script.  The packaged /etc/cron.daily/aide script
should instead be calling a wrapper script by a different name.  It
would be much easier for those two scripts to coordinate between each
other.  This would avoid tripping over other uses of the program.
Between those two scripts all of the semaphoring and modular config
file processing can be handled without causing problems to other
unrelated scripts.

Let's see, /etc/cron.daily/aide calls /usr/bin/aiderun which
concatenates the config file and semaphores the output database to
protect against cron tasks overrunning themselves.  It then calls
/usr/bin/aide the binary to perform the activity.  This avoids any
conflict with other scripts using aide the binary.  That seems like a
clean approach to me.

What do you think?

Bob