Comment 3 for bug 351378

Attached is an archive containing the output of:

  # strace -ff -F -o /tmp/dhclient.strace dhclient eth0:0
  There is already a pid file /var/run/dhclient.pid with pid 134519072
  Internet Systems Consortium DHCP Client V3.0.6
  Copyright 2004-2007 Internet Systems Consortium.
  All rights reserved.
  For info, please visit http://www.isc.org/sw/dhcp/

  SIOCSIFADDR: Permission denied
  SIOCSIFFLAGS: Permission denied
  SIOCSIFFLAGS: Permission denied
  Bind socket to interface: No such device

Some interesting bits include:

From dhclient.strace.9271-avahi-autoipd:

execve("/usr/sbin/avahi-autoipd", ["/usr/sbin/avahi-autoipd", "-k", "eth0:0"], [/* 7 vars */]) = 0
[...]
open("/var/run//avahi-autoipd.eth0:0.pid", O_RDWR) = -1 ENOENT (No such file or directory)
write(2, "Failed to kill daemon: No such f"..., 48) = 48
write(2, "\n", 1) = 1
exit_group(1) = ?

That avahi-autoipd is trying to access /var/run/avahi-autoipd.eth0:0.pid may be by design, or may be a bug. I don't know enough about avahi to know whether it normally has a separate daemon running for each interface, and if so, whether that should apply to virtual interfaces.

I saw a similar error in some of the messages output by dhclient, where it was trying to create a PID file for itself that incorporated the virtual device name. Again, should it be running a separate instance of the daemon for each virtual interface?

And from dhclient.strace.9272-ifconfig:

execve("/sbin/ifconfig", ["ifconfig", "eth0:0", "inet", "0", "up"], [/* 7 vars */]) = 0
[...]
socket(PF_FILE, SOCK_DGRAM, 0) = 3
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
access("/proc/net/if_inet6", R_OK) = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 6
[...]
ioctl(4, SIOCSIFADDR, 0xbfdbeb00) = -1 EACCES (Permission denied)
dup(2) = 7
fcntl64(7, F_GETFL) = 0x2 (flags O_RDWR)
fstat64(7, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0b000
_llseek(7, 0, 0xbfdbe498, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(7, "SIOCSIFADDR: Permission denied\n", 31) = 31
close(7) = 0
munmap(0xb7f0b000, 4096) = 0
ioctl(4, SIOCGIFFLAGS, {ifr_name="eth0:0", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, 0xbfdbe9e8) = -1 EACCES (Permission denied)
dup(2) = 7
fcntl64(7, F_GETFL) = 0x2 (flags O_RDWR)
fstat64(7, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0b000
_llseek(7, 0, 0xbfdbe438, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(7, "SIOCSIFFLAGS: Permission denied\n", 32) = 32
close(7) = 0
munmap(0xb7f0b000, 4096) = 0
ioctl(4, SIOCGIFFLAGS, {ifr_name="eth0:0", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, 0xbfdbe9e8) = -1 EACCES (Permission denied)
dup(2) = 7
fcntl64(7, F_GETFL) = 0x2 (flags O_RDWR)
fstat64(7, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0b000
_llseek(7, 0, 0xbfdbe438, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(7, "SIOCSIFFLAGS: Permission denied\n", 32) = 32
close(7) = 0
munmap(0xb7f0b000, 4096) = 0
exit_group(-1) = ?

This call to ifconfig seems to be the source of the errors. I'm puzzled how you can get an EACCES error on a newly created socket while running as root, if SELinux or AppArmor isn't involved (as far as I'm aware).

If I run the above command directly:

# /sbin/ifconfig eth0:0 inet 0 up
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address

Sure enough, same results. Using 0.0.0.0 also fails, but substitute a real IP address for the zero placeholder and we get:

# /sbin/ifconfig eth0:0 inet 192.168.0.210 up
# ifconfig
[...]
eth0:0 Link encap:Ethernet HWaddr 00:04:61:4b:d1:33
          inet addr:192.168.0.210 Bcast:192.168.0.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          Interrupt:16
[...]

It seems the EACCES error is incorrect and misleading, and the call should instead return an error indicating that the address is invalid.

I'm assuming dhclient is calling ifconfig in this fashion in order to create the virtual device, and if successful, is going to go back after obtaining an IP address via DHCP and update the interface.

I gather some internals in ifconfig or the kernel changed.

 -Tom