Bad interface name
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ufw (Ubuntu) |
Fix Released
|
Medium
|
Jamie Strandboge | ||
Bionic |
Fix Released
|
Medium
|
Jamie Strandboge | ||
Cosmic |
Fix Released
|
Medium
|
Jamie Strandboge | ||
Disco |
Fix Released
|
Medium
|
Jamie Strandboge |
Bug Description
[Impact]
ufw's interface name's or both too strict (this bug) and too loose (iptables has its own limits). Adjust the interface name checks to match those of the kernel.
[Test Case]
$ sudo ufw --dry-run allow in on i-1|grep i-1
### tuple ### allow any any 0.0.0.0/0 any 0.0.0.0/0 in_i-1
-A ufw-user-input -i i-1 -j ACCEPT
### tuple ### allow any any ::/0 any ::/0 in_i-1
-A ufw6-user-input -i i-1 -j ACCEPT
With an unpatched ufw, the above results in:
$ sudo ufw --dry-run allow in on i-1|grep i-1
ERROR: Bad interface name
[Regression Potential]
Risk of regression is considered low since the updated allow more than what is currently allowed, but not more than what iptables allows. See:
https:/
= Original description =
Is there a reason to restrict interface's name in ufw?
Should ufw accept what iptables accept as iface name?
I've a vpn with lot of nodes, its iface name contain a '-' so cannot use ufw on it.
I've found the check here and cannot found a reason for it:
http://
thanks
Changed in ufw (Ubuntu): | |
status: | Triaged → In Progress |
Changed in ufw (Ubuntu Cosmic): | |
status: | New → Triaged |
Changed in ufw (Ubuntu Bionic): | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in ufw (Ubuntu Cosmic): | |
importance: | Undecided → Medium |
Changed in ufw (Ubuntu Bionic): | |
assignee: | nobody → Jamie Strandboge (jdstrand) |
Changed in ufw (Ubuntu Cosmic): | |
assignee: | nobody → Jamie Strandboge (jdstrand) |
description: | updated |
Changed in ufw (Ubuntu Bionic): | |
status: | Triaged → In Progress |
Changed in ufw (Ubuntu Cosmic): | |
status: | Triaged → In Progress |
Thank you for using Ubuntu and reporting a bug. We restrict the interface name simply for input validation and after doing a bit of research, I see no reason why we can't allow '-' and '_' in the interface name. I'll adjust trunk for that, but it may be expanded further.