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

[Marc Haber]

On Mon, May 15, 2006 at 03:40:40AM -0600, Bob Proulx wrote:
> 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.

Agreed. In that case, it would be adviseable to directly run aide.real.

> 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.

Right.

> But that means extracting the output file from the config file.  But
> that should work.

Yes. I am, however, reluctant to do this in a wrapper for fear of
complexity. The goal for the wrapper is to fit the majority of cases.

This should be addressed in aide itself. I have opened a ticket in the
upstream bug database,
https://sourceforge.net/tracker/index.php?func=detail&aid=1488776&group_id=86976&atid=581582.

While you have a point, I think that extending the wrapper is gold
plating while it is always possible for the user to directly invoke
aide.

> > > 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 have had database corruption in cases where a manually invoked, long
running aide process was disturbed by cron kicking of a scheduled check.

> 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.

The wrapper does this nicely.

> > > 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.

It clearly is sub-optimal, but I still think that the current behavior
is a good compromise until aide itself properly handles this conflict.

> > > 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

Aah!

Sorry. You're of course right.

> > > 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.)

Both options would be acceptable, IMO.

> 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.

Agreed. Please consider whether the current "breakage" does really
need fixing.

> 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.

They are only tripping over each other when the local user does not
understand the way the Debian packages are built.

> 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.

Actually, the wrapper pre-dates the modular configuration file and was
originally introduced for the lock handling.

> 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.

Partly agreed.

> 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.

I'll consider this. I don't like the potential to break existing
setups though.

Additionally, I think that in this case, the aide binary should be
compiled to use /dev/null as configuration file and /tmp/aide as a
database to keep it from interfering with the database/config set used
by the system 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?

I'll need to ponder about that.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835