Re: 【DISCUSS】The configuration of Commitlog archiving

Thanks Jon But should we at least add the ability of dynamic closing to the archive that Stefan mentioned before ? Jon Haddad 于2024年9月25日周三 01:16写道： > I categorize this as Not a Problem. > > So far the two main justifications have been operator error and a fairly > convoluted series of steps to

Re: 【DISCUSS】The configuration of Commitlog archiving

I categorize this as Not a Problem. So far the two main justifications have been operator error and a fairly convoluted series of steps to an already compromised database. I don't view either of them as a reason to inconvenience users. If someone wants to avoid the shell command, what's wrong wi

Re: 【DISCUSS】The configuration of Commitlog archiving

Hello，are there any new updates？🤔 guo Maxwell 于2024年9月18日 周三下午4:06写道： > Do you have any new updates on this DISCUSS ? > > - The reason this pattern is popular is it allows extension of > functionality ahead of the database. Some people copy to a NAS/SAN. Some > people copy to S3. Some people cop

Re: 【DISCUSS】The configuration of Commitlog archiving

Do you have any new updates on this DISCUSS ? - The reason this pattern is popular is it allows extension of functionality ahead of the database. Some people copy to a NAS/SAN. Some people copy to S3. Some people copy to their own object storage that isn’t s3 compatible. “Compress and move” is su

Re: 【DISCUSS】The configuration of Commitlog archiving

On Wed, Sep 4, 2024 at 8:34 PM Jon Haddad wrote: > I thought about this a bit over the last few days, and there's actually > quite a few problems present that would need to be addressed. > > *Insecure JMX* > > First off - if someone has access to JMX, the entire system is already > compromised.

Re: 【DISCUSS】The configuration of Commitlog archiving

I thought about this a bit over the last few days, and there's actually quite a few problems present that would need to be addressed. *Insecure JMX* First off - if someone has access to JMX, the entire system is already compromised. A bad actor can mess with the cluster topology, truncate tables

Re: 【DISCUSS】The configuration of Commitlog archiving

Yes, commitlog_archiving.properties is used both for archiving and restoration for commitlog, but we don't have a tool or interface to do commitlog restore online which I have created the commitlog tool issue CASSANDRA-15156 . > > By default

Re: 【DISCUSS】The configuration of Commitlog archiving

Scott is right that this is also coming from us having a MBean method which allows commands to be changed in runtime. The solution to that was that we can prevent it from changing dynamically by having a configuration property, which is actually by default set to false so FQL archiving is ever poss

Re: 【DISCUSS】The configuration of Commitlog archiving

Thank you very much for everyone's replies, they are all very valuable feedback to me. 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?

Re: 【DISCUSS】The configuration of Commitlog archiving

+1 to Scott’s comments. Once you expose those YAML config params outside of a single node which many of us do, this becomes an RCE attack vector. Something more structured as Scott proposes, similar to snapshots, would be preferred. Would recommend a CEP. Jordan On Fri, Aug 30, 2024 at 20:58 C. S

Re: 【DISCUSS】The configuration of Commitlog archiving

I appreciate this report and would love to work toward the direction it recommends.I’m also familiar with past concerns raised by others with our FQL configuration parameters that allow passing shell commands for FQL segment archival.We bias toward ensuring an MBean exists for dynamic modification

Re: 【DISCUSS】The configuration of Commitlog archiving

I'm not sure what is the concern here. Is it a malicious user exploiting this? Or human error with unintended consequences? For malicious user, in order to exploit this, an attacker needs to be able to write to the config file. The config file on Linux by default is owned by the root user and

Re: 【DISCUSS】The configuration of Commitlog archiving

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? > On

Re: 【DISCUSS】The configuration of Commitlog archiving

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 wrote: > Thanks for bringing this to the mailing list. I quickly skimmed the > feature and I agree w

Re: 【DISCUSS】The configuration of Commitlog archiving

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 i