PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001273PacketFencecorepublic2011-09-21 15:542011-10-24 20:17
Reporterdwuelfrath 
Assigned Toobilodeau 
PriorityhighSeveritymajorReproducibilityrandom
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.0.0 
Target Version3.0.2Fixed in Version3.0.2 
fixed in git revision
fixed in mtn revision81d568ba1a2fecffe8e76b3a869c313b596138c0
Summary0001273: enforcement calls should be executed by root
Descriptiongot an issue with iptables locks when captive portal (apache) tryed to change the iptables rules and there was a lock issued by a root process (pfcmd)
Steps To Reproduce
Additional InformationSep 21 15:29:06 redir.cgi(0) INFO: 90:e6:ba:70:e7:4b being redirected (ModPerl::ROOT::ModPerl::PerlRun::usr_local_pf_html_captive_2dportal_redir_2ecgi::handler)
Sep 21 15:29:06 redir.cgi(0) INFO: MAC 90:e6:ba:70:e7:4b shouldn't reach here. Calling access re-evaluation. Make sure your network device configuration is correct. (ModPerl::ROOT::ModPerl::PerlRun::usr_local_pf_html_captive_2dportal_redir_2ecgi::handler)
Sep 21 15:29:06 redir.cgi(0) INFO: re-evaluating access for node 90:e6:ba:70:e7:4b (redir.cgi called) (pf::enforcement::reevaluate_access)
Sep 21 15:29:06 redir.cgi(0) INFO: MAC: 90:e6:ba:70:e7:4b stated changed, adapting firewall rules for proper enforcement (pf::inline::performInlineEnforcement)
Sep 21 15:29:06 redir.cgi(0) FATAL: Cannot access lockfile:[/var/lock/iptables_cmd_lock] Permission denied at /usr/local/pf/lib/IPTables/Interface.pm line 72
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-09-21 15:54dwuelfrathNew Issue
2011-09-21 22:12obilodeauNote Added: 0002230
2011-09-21 22:12obilodeauPrioritynormal => high
2011-09-21 22:12obilodeauSeverityminor => major
2011-09-21 22:12obilodeauProduct Version => 3.0.0
2011-09-21 22:12obilodeauTarget Version3.0.0 => +1
2011-10-24 08:53obilodeauStatusnew => assigned
2011-10-24 08:53obilodeauAssigned To => obilodeau
2011-10-24 12:07obilodeaumtn revision => 81d568ba1a2fecffe8e76b3a869c313b596138c0
2011-10-24 12:07obilodeauNote Added: 0002376
2011-10-24 12:07obilodeauStatusassigned => resolved
2011-10-24 12:07obilodeauFixed in Version => +1
2011-10-24 12:07obilodeauResolutionopen => fixed
2011-10-24 20:15obilodeauTarget Version+1 => 3.0.2
2011-10-24 20:15obilodeauNote Added: 0002389
2011-10-24 20:16obilodeauStatusresolved => closed
2011-10-24 20:17obilodeauFixed in Version+1 => 3.0.2

Notes
(0002230)
obilodeau   
2011-09-21 22:12   
targeted to +1, affecting 3.0. increased priority.

If you are bitten by this and desperately need a workaround we probably can come up with something quickly. Contact us here, on the mailing list or on IRC.
(0002376)
obilodeau   
2011-10-24 12:07   
fix committed. Here's the commit entry:

refactoring: made sure that access re-evaluation runned in privileged daemons. Fixes 0001273

Quite an intrusive fix:
Everyone except pfdhcplistener in inline enforcement now calls pf::enforcement to request a VLAN or firewall 
rule change. This includes captive portal, pfcmd, pfcmd_vlan (previously flip.pl). pf::enforcement now 
emit proper traps to pfsetvlan (reAssignVlan, desAssociate and the new firewallRequest) and then pfsetvlan 
takes care of calling SNMP modules (port-sec), pfcmd_vlan (dot1x, MAC-Auth) or pf::inline (firewall).


pfsetvlan runs as root so firewall changes are done as root. Doing so we also chopped one or two locationlog 
lookups so that's a good thing.
- Inline API bump: new method call in pf::inline: isInlineEnforcementRequired
- chopped advanced.adjustswitchportvlanscript config parameter since everything is now through pf::enforcement


http://www.packetfence.org/bugs/view.php?id=1273 [^]
(0002389)
obilodeau   
2011-10-24 20:15   
fix released in 3.0.2