bitbake wpa-supplicant-0.6.3 fails (OSError)

[cfriedt]

OE Build Configuration:

BB_VERSION = "1.8.11"
METADATA_BRANCH = "<unknown>"
METADATA_REVISION = "<unknown>"
TARGET_ARCH = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE = "om-gta02"
DISTRO = "openmoko"
DISTRO_VERSION = "-20090105"
TARGET_FPU = "soft"

I'm just using the 'stable' git tree, atm.

I believe that the .bb recipe is trying to run a script of some kind located at

'build/tmp/work/armv4t-angstrom-linux-gnueabi/wpa-supplicant-0.6.3-r3/install/wpa-supplicant/etc/network/if-post-down.d/wpasupplicant'

The file above is actually only a symbolic link to

/etc/wpa_supplicant/ifupdown.sh

which does not exist on my machine.

In any event, the bb recipe should not attempt to execute any script that controls a network interface on the build machine.

I'll attach the build log and see if I can put a fix together as well.

[cfriedt]

output of 'bitbake wpa-supplicant'

[cfriedt]

Sorry, this should not have been posted here - I was trying to log in to admin-trac.openmoko.org and for some reason I was directed here.

Why don't we just have a bugzilla?

[cfriedt]

Again, sorry - according to ​http://wiki.openmoko.org/wiki/Bug_Filing_Policy , this IS the correct place to file a bug.

I still find it very odd that we don't just use bugzilla.

[cfriedt]

Well, I've identified the culprit in my issue. It seems that while examining bitbake encounters an Error 13 (EPERM) causing the build to fail.

Checking out packages/wpa-supplicant/wpa-suplicant-0.6.inc, at around line 65, I noticed that there are two symbolic links created in the image dir.

do_install () {
...

ln -s /etc/wpa_supplicant/ifupdown.sh ${D}${sysconfdir}/network/if-pre-up.d/wpasupplicant
ln -s /etc/wpa_supplicant/ifupdown.sh ${D}${sysconfdir}/network/if-post-down.d/wpasupplicant

...
}

On my machine, /etc/wpa_supplicant is owned by root:root and has mode 750. Hence the EPERM.

Now - rule #1 - there should be no access to files on the build system by bitbake during the install stage at all. By (obvious?) inspection, there really is none! The install process is instructed to create a symbolic link called 'etc/network/if-pre-up.d/wpasupplicant' to point to a location (/etc/wpa_supplicant/ifupdown.sh). The location that any symbolic link points to should be (to some extent) irrelevent.

So I looked into openembedded/classes/package.bbclass, where the exception was coming from, around line 450, stat() is called on the file in the image directory ($D). When stat() is called on the symbolic link, it actually follows the symbolic link, causing the EPERM.

A slight modification of package.bbclass is necessary in my opinion, so that inappropriate stat() calls are not made to symbolic links.

Does anyone know how? I'm still a bit of a n00b when it comes to python.

[cfriedt]

openembedded-package-bbclass-ignore-errno-EACCES.patch

[cfriedt]

Python n00b or not, I think I may have found the fix. I can't be sure if this problem is actually in OpenEmbedded?'s package.bbclass, or whether it is an error or Python's os.stat(). My Python version is 2.5.2 incidentally.

My problem was this:

1) os.stat() is called on a symbolic link

/home/cfriedt/openmoko/oe/build/tm
p/work/armv4t-angstrom-linux-gnueabi/wpa-supplicant-0.6.3-r3/image/etc/network/if-post-down.d/wpasupplicant

which points to

/etc/wpa_supplicant/ifupdown.sh

2) os.stat(), for some reason, follows the symbolic link and attempts to perform another os.stat() on the target of the link (far before the os.readlink() function is called on the link itself)

3) If the target of the link is contained within, or is itself, unreadable by the current user, then os.stat() throws an exception, errno.EACCES (13).

I'm not going to bother submitting a patch for python, although I guess I could submit a bug report. There is, however, an attachment in this bug report that should fix OpenEmbedded?.

I gave it quite a bit of consideration, and I can't think of any case where this would actually pose a security threat in OE packages - it's more of glue code to handle a shortcoming in either python's or Linux's implementation of the stat() syscall.

[cfriedt]

Submitted bug 4963 at bugs.openembedded.net.

Just a final thought -

It might be a better idea to substitute os.lstat() instead of os.stat() in openembedded/classes/packages.bbclass, rather than ignoring the OSError errno.EACCES exception.

[andy]

Moving off "system software" to "Distro"