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

[Alexandre DERUMIER]

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

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