I don't really understand what benefit adding restrictions would serve. Would it be hard coded in C* itself, or configurable? If it's configurable, then are we just making users enter their commands twice? This is meant to be used by an operator, so who's actually protected by an allow-list?
> 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. I don't see how anyone using this functionality today is any better off by these restrictions. The entire point here is the flexibility, otherwise it would make sense to have all this logic in C* itself. If I want to use rclone or aws-cli to archive my commit logs that's my prerogative. Making it pluggable, and in Java, is the only option that would make any sense to me, but I bet the majority of use cases would be to call a shell script. Jon On Fri, Aug 30, 2024 at 10:06 AM Štefan Miklošovič <smikloso...@apache.org> wrote: > 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. 😀 >> > >> >
