Thanks for bringing this to the mailing list. I quickly skimmed the feature and I agree with you that having an arbitrary command executed could be dangerous. However, this is a 12 year old feature and so am guessing there are people using it.
As far as locking down the feature, I don't think it is feasible to lock it down as it allows execution of arbitrary scripts. Dinesh On Fri, Aug 30, 2024 at 9:14 AM guo Maxwell <cclive1...@gmail.com> wrote: > > Commitlog has the ability of archive log file, see > CommitLogArchiver.java, we can achieve the purpose of archive and restore > commitlog by configuring archive_command and restore_command in > commitlog_archiving.properties.The archive_command and restore_command can be > some linux/unix shell command. However, I found that the shell command can > actually be filled with any script, even if "rm -rf" .I have tested this > situation and it finally succeeded with my test file being deleted. > > Personally, I think it is a dangerous behavior, because if there are no > system-level restrictions and users are allowed to do anything in these shell > commands. So here I want to discuss with you whether it is necessary to > impose any restrictions on use, or do we need a new way of > archiving/restoring commitlog? > > Of course, before that, I would also like to ask, how many people are using > archive and restore of commitlog? It seems that the commitlog archive code > has not been updated for a long time. > > I have two ideas. > One is to make some restrictions on the command context based on the existing > usage methods, such as strictly only allowing the current cp/mv/ln %path to > %name.Other redundant strings in the command are not allowed. > Another one , As I roughly investigated the archive of mysql and pg. They do > not give users too much space (I am talking about letting users define their > own archiving command ), and archive directly to a designated location. For > us, I feel that we can refer to c * Incremental backup of sstable, add a > hardlink to the commitlog to the specified location, but this place may > modify the original configuration method, such as setting the archive > location and restoring location of the node through nodetool and deprecate > the commitlog_archiving.properties configuration. > > I am just putting forward some views here, and looking forward to your > feedback. 😀 >
