[pve-devel] firewall : possible bug/race when cluster.fw is replicated and rules are updated ?

[Thomas Lamprecht]

On 1/9/19 11:18 AM, Alexandre DERUMIER wrote:
>>> I can trigger the bug with simply restart pve-cluster service.  (I think it umount/mount /etc/pve).
>>> That's simply break my firewalled connections in my vms.... 
> 
> Could we add a simple check to see if /etc/pve is mounted ?

yes, sounds reasonable, as this happens on every pve-cluster update.

> 
> ----- Mail original -----
> De: "aderumier" <aderumier at odiso.com>
> À: "pve-devel" <pve-devel at pve.proxmox.com>
> Envoyé: Mercredi 9 Janvier 2019 11:06:26
> Objet: Re: [pve-devel] firewall : possible bug/race when cluster.fw is replicated and rules are updated ?
> 
>>> Booting node, pve-cluster fails to start/mount. But, in this case you're done 
>>> anyway as either you: 
>>> * change the "Wants=pve-cluster" to "Requires=üpve-cluster", which then result 
>>> in no pve-firewall service running at all 
>>> * or keep it as is, which starts the pve-firewall service nonetheless, but with 
>>> default off as the config cannot be read. 
> 
>>> The latter may even be slightly better as as soon as pve-cluster got repaired 
>>> the firewall service starts to work correctly automatically... 
> 
> I can trigger the bug with simply restart pve-cluster service. (I think it umount/mount /etc/pve). 
> That's simply break my firewalled connections in my vms.... 
> 
> 
> 
> 
> 
> ----- Mail original ----- 
> De: "Thomas Lamprecht" <t.lamprecht at proxmox.com> 
> À: "pve-devel" <pve-devel at pve.proxmox.com>, "aderumier" <aderumier at odiso.com> 
> Envoyé: Mercredi 9 Janvier 2019 09:49:44 
> Objet: Re: [pve-devel] firewall : possible bug/race when cluster.fw is replicated and rules are updated ? 
> 
> On 1/9/19 9:17 AM, Thomas Lamprecht wrote: 
>> On 1/9/19 8:36 AM, Alexandre DERUMIER wrote: 
>>>>> Hmm, but if one wants to restore the defaults by simply deleting the file he'd 
>>>>> need to restart the firewall daemon too. Not really sure if this is ideal 
>>>>> either... Even if we could do heuristics for if the file was really 
>>>>> removed/truncated (double checks) that would be just feel hacky and as said 
>>>>> above, such actions can get you in trouble with all processes where there are 
>>>>> reader writers, so this should be handled by the one updating the file. 
>>>
>>> Ok I understand. 
>>> I'm also think of case, where we could have a corosync/network failure, 
>>> where /etc/pve couldn't be mounted anymore or not readable, 
>>> that mean that in this case the firewall will be off too. 
>>> That's seem bad for security.... 
>>
>> Yeah, that's a valid concern. 
> 
> Argh, wrong. If there's no quorum network failure you still have the old state 
> in the cluster.conf represented, the filesystem just went into read only mode 
> so modifications aren't possible anyway. 
> 
>> Maybe we could simply omit changing rules or anything else if we are not quorate? 
>> Would seem like the right thing to do, because in that case we cannot assume 
>> anything so it's best to keep the last valid state intact. 
>>
> 
> So this is already the behaviour there. And pve-firewall depends on pve-cluster, 
> so it should only start after it mounted. The single issue could be: 
> 
> Booting node, pve-cluster fails to start/mount. But, in this case you're done 
> anyway as either you: 
> * change the "Wants=pve-cluster" to "Requires=üpve-cluster", which then result 
> in no pve-firewall service running at all 
> * or keep it as is, which starts the pve-firewall service nonetheless, but with 
> default off as the config cannot be read. 
> 
> The latter may even be slightly better as as soon as pve-cluster got repaired 
> the firewall service starts to work correctly automatically... 
> 
> _______________________________________________ 
> pve-devel mailing list 
> pve-devel at pve.proxmox.com 
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>