There is (1), we can do it similarly for commit log archiving (1) https://github.com/apache/cassandra/commit/aafb4d19448f12ce600dc4e84a5b181308825b32
On Fri, Aug 30, 2024 at 6:56 PM Dinesh Joshi <djo...@apache.org> wrote: > 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. 😀 > > >
