Bug#367337: [Pkg-aide-maintainers] Bug#367337: /var/run/aide.lock breaks non-root use of aide
package aide tags #367337 - patch # the patch is not acceptable in this form due to reasons outlined in # the message body. thanks On Mon, May 15, 2006 at 01:23:03AM -0600, Bob Proulx wrote: > Use of /var/run/aide.lock breaks non-root use of aide. How about using $HOME/.aide.lock if the wrapper is not invoked as root? > 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. > 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. > Also when using > $@ you almost always want "$@". Agreed. > 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? > 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. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367337: [Pkg-aide-maintainers] Bug#367337: /var/run/aide.lock breaks non-root use of aide
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
Bug#367337: [Pkg-aide-maintainers] Bug#367337: /var/run/aide.lock breaks non-root use of aide
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
