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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
