HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Leon Woestenberg]

Hello all,

for those of you using insane.bbclass, it will now correctly detect
wrong RPATH's in shared libraries and fail on them.

Unfortunately, as we have not fixed wrong RPATH's yet in our shared
library handling, this will cause builds using insane.bbclass to fail.

See bug #2140.

I hope to be able to fix the .so RPATH stuff as well, but any help is welcomed.

Regards,
-- 
Leon

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Justin Patrin]

On 4/26/07, Leon Woestenberg <leon.woestenberg@gmail.com> wrote:
> Hello all,
>
> for those of you using insane.bbclass, it will now correctly detect
> wrong RPATH's in shared libraries and fail on them.
>
> Unfortunately, as we have not fixed wrong RPATH's yet in our shared
> library handling, this will cause builds using insane.bbclass to fail.
>
> See bug #2140.
>
> I hope to be able to fix the .so RPATH stuff as well, but any help is welcomed.
>

So what you're saying is that angstrom won't build until the RPATH
problems are fixed? Kind of sucks for those users who don't know how
to fix the problem. I'd suggest that this be made a warning instead of
a failure (or have a conf entry that makes it one or the other).

-- 
Justin Patrin

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Patrin schreef:
> On 4/26/07, Leon Woestenberg <leon.woestenberg@gmail.com> wrote:
>> Hello all,
>>
>> for those of you using insane.bbclass, it will now correctly detect
>> wrong RPATH's in shared libraries and fail on them.
>>
>> Unfortunately, as we have not fixed wrong RPATH's yet in our shared
>> library handling, this will cause builds using insane.bbclass to fail.
>>
>> See bug #2140.
>>
>> I hope to be able to fix the .so RPATH stuff as well, but any help is welcomed.
>>
> 
> So what you're saying is that angstrom won't build until the RPATH
> problems are fixed? Kind of sucks for those users who don't know how
> to fix the problem. I'd suggest that this be made a warning instead of
> a failure (or have a conf entry that makes it one or the other).

It is a huge gaping security hole, so it is indeed an error.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGMOMQMkyGM64RGpERAqoYAKCHCwKJaUuL+1REjY/CRBYMxa7afACfTbs3
4ErvVInAL06DjxXwHDTtLb0=
=sa1b
-----END PGP SIGNATURE-----

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Justin Patrin]

On 4/26/07, Koen Kooi <koen@dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Justin Patrin schreef:
> > On 4/26/07, Leon Woestenberg <leon.woestenberg@gmail.com> wrote:
> >> Hello all,
> >>
> >> for those of you using insane.bbclass, it will now correctly detect
> >> wrong RPATH's in shared libraries and fail on them.
> >>
> >> Unfortunately, as we have not fixed wrong RPATH's yet in our shared
> >> library handling, this will cause builds using insane.bbclass to fail.
> >>
> >> See bug #2140.
> >>
> >> I hope to be able to fix the .so RPATH stuff as well, but any help is welcomed.
> >>
> >
> > So what you're saying is that angstrom won't build until the RPATH
> > problems are fixed? Kind of sucks for those users who don't know how
> > to fix the problem. I'd suggest that this be made a warning instead of
> > a failure (or have a conf entry that makes it one or the other).
>
> It is a huge gaping security hole, so it is indeed an error.
>

A "huge gaping security hole" that requires you to download a
malicious ipk with malicious libraries which figures out what your
build path was, then installs those libraries there.

Or you could just download a malicious ipk which overwrites the actual
libraries.

I don't see what's hude or gaping about this.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFGMOMQMkyGM64RGpERAqoYAKCHCwKJaUuL+1REjY/CRBYMxa7afACfTbs3
> 4ErvVInAL06DjxXwHDTtLb0=
> =sa1b
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Justin Patrin

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leon Woestenberg schreef:
> Hello all,
> 
> for those of you using insane.bbclass, it will now correctly detect
> wrong RPATH's in shared libraries and fail on them.
> 
> Unfortunately, as we have not fixed wrong RPATH's yet in our shared
> library handling, this will cause builds using insane.bbclass to fail.
> 
> See bug #2140.
> 
> I hope to be able to fix the .so RPATH stuff as well, but any help is welcomed.

Attached patch replaces bogus rpaths with '/lib' inside insane.bbclass. There are several
things wrong with this approach, but it's a start.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGMPvfMkyGM64RGpERAjz8AJ9fl8l2SMw586tr6HhKtE7PCoS7wwCdEgi7
5IQYUSdNXXFgeYHW3mGtvro=
=RrbB
-----END PGP SIGNATURE-----

[-- Attachment #2: chrpath.patch --]
[-- Type: text/x-patch, Size: 1735 bytes --]

# 
# old_revision [4363d4f2067c14e0433c8a93cf6595a62ffd8ea1]
# 
# patch "classes/insane.bbclass"
#  from [3a03bd01885af7a8749b8d7c891e968eadae8bea]
#    to [908828866e30c41cff63a3fa4a7aac7d30924e83]
# 
============================================================
--- classes/insane.bbclass	3a03bd01885af7a8749b8d7c891e968eadae8bea
+++ classes/insane.bbclass	908828866e30c41cff63a3fa4a7aac7d30924e83
@@ -202,10 +202,13 @@ def package_qa_check_rpath(file,name,d):
     """
     import bb, os
     scanelf = os.path.join(bb.data.getVar('STAGING_BINDIR_NATIVE',d,True),'scanelf')
+    chrpath = os.path.join(bb.data.getVar('STAGING_BINDIR_NATIVE',d,True),'chrpath')
     bad_dir = bb.data.getVar('TMPDIR', d, True) + "/work"
     bad_dir_test = bb.data.getVar('TMPDIR', d, True)
     if not os.path.exists(scanelf):
-        bb.fatal("Can not check RPATH scanelf not found")
+        bb.fatal("Can not check RPATH, scanelf (part of pax-utils-native) not found")
+    if not os.path.exists(chrpath):
+        bb.fatal("Can not fix RPATH, chrpath (part of chrpath-native) not found")
     if not bad_dir in bb.data.getVar('WORKDIR', d, True):
         bb.fatal("This class assumed that WORKDIR is ${TMPDIR}/work... Not doing any check")
 
@@ -215,7 +218,9 @@ def package_qa_check_rpath(file,name,d):
         if bad_dir_test in line:
             package_qa_write_error( 1, name, file, d)
             bb.error("QA Issue package %s contains bad RPATH %s in file %s" % (name, line, file))
-            return False
+	    bb.message("Fixing RPATH for you in %s" % file)
+	    os.popen("%s -r /lib %s" % (chrpath,file))
+            return True
     return True
 
 def package_qa_check_devdbg(path, name,d):

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Leon Woestenberg schreef:
>> Hello all,
> 
>> for those of you using insane.bbclass, it will now correctly detect
>> wrong RPATH's in shared libraries and fail on them.
> 
>> Unfortunately, as we have not fixed wrong RPATH's yet in our shared
>> library handling, this will cause builds using insane.bbclass to fail.
> 
>> See bug #2140.
> 
>> I hope to be able to fix the .so RPATH stuff as well, but any help is welcomed.
> 
> Attached patch replaces bogus rpaths with '/lib' inside insane.bbclass. There are several
> things wrong with this approach, but it's a start.

For one, bb.message doesn't exist.

updated patch attached.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGMQNUMkyGM64RGpERAkymAKCjXS5XaosSdHvTEefmhc0PJgIrXwCdGRL/
PaUz8C7MxY/84UNWcBHcT48=
=/STS
-----END PGP SIGNATURE-----

[-- Attachment #2: chrpath.patch --]
[-- Type: text/x-patch, Size: 1746 bytes --]

# 
# old_revision [4363d4f2067c14e0433c8a93cf6595a62ffd8ea1]
# 
# patch "classes/insane.bbclass"
#  from [3a03bd01885af7a8749b8d7c891e968eadae8bea]
#    to [52bd5e7c8bced0a26f41f5a38b5f46601b40d988]
# 
============================================================
--- classes/insane.bbclass	3a03bd01885af7a8749b8d7c891e968eadae8bea
+++ classes/insane.bbclass	52bd5e7c8bced0a26f41f5a38b5f46601b40d988
@@ -202,10 +202,13 @@ def package_qa_check_rpath(file,name,d):
     """
     import bb, os
     scanelf = os.path.join(bb.data.getVar('STAGING_BINDIR_NATIVE',d,True),'scanelf')
+    chrpath = os.path.join(bb.data.getVar('STAGING_BINDIR_NATIVE',d,True),'chrpath')
     bad_dir = bb.data.getVar('TMPDIR', d, True) + "/work"
     bad_dir_test = bb.data.getVar('TMPDIR', d, True)
     if not os.path.exists(scanelf):
-        bb.fatal("Can not check RPATH scanelf not found")
+        bb.fatal("Can not check RPATH, scanelf (part of pax-utils-native) not found")
+    if not os.path.exists(chrpath):
+        bb.fatal("Can not fix RPATH, chrpath (part of chrpath-native) not found")
     if not bad_dir in bb.data.getVar('WORKDIR', d, True):
         bb.fatal("This class assumed that WORKDIR is ${TMPDIR}/work... Not doing any check")
 
@@ -215,7 +218,9 @@ def package_qa_check_rpath(file,name,d):
         if bad_dir_test in line:
             package_qa_write_error( 1, name, file, d)
             bb.error("QA Issue package %s contains bad RPATH %s in file %s" % (name, line, file))
-            return False
+            bb.note("Fixing RPATH for you in %s" % file)
+            os.popen("%s -r /lib %s" % (chrpath,file))
+            return True
     return True
 
 def package_qa_check_devdbg(path, name,d):

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Leon Woestenberg]

Hello Justin, Koen, others,

On 4/26/07, Koen Kooi <koen@dominion.kabel.utwente.nl> wrote:
> Attached patch replaces bogus rpaths with '/lib' inside insane.bbclass. There
> are several things wrong with this approach, but it's a start.
>
I would consider this the best approach until we have figured out
where we have to move this to instead. Your patch will:
- remove the host paths, or replace them with something safe: /lib
- thus remove a theoratical security hole if /tmp is involved.
- thus speed up library loading on the target, by removing the
overhead of the target's linker trying a handful (~15) paths that will
not resolve for sure.

The proper place is somewhere in the shared library handling. Probably
we do not need 'chrpath' but possibly we can override the rpath
directly during linking.

This needs some investigation, but I suggest we include your patch so
that builds are not broken anymore.

Regards,
-- 
Leon

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Leon Woestenberg]

After some work, I couldn't get chrpath-native nor chrpath-cross to
deal with the target's ELF file (x86_64 host, i686 target):

./chrpath -l /home/leon/sandbox/e520/openembedded/build/tmp/work/i686-angstrom-linux/glibc-2.5-r5/install/glibc-dbg/usr/bin/.debug/localedef
`/home/leon/sandbox/e520/openembedded/build/tmp/work/i686-angstrom-linux/glibc-2.5-r5/install/glibc-dbg/usr/bin/.debug/localedef'
probably isn't a 64-bit LSB-first ELF file.
elf_open: Exec format error

although koen reported success with his host/target combo.

Now, for the moment, should we change insane.bbclass to indicate a
warning instead of an error on illegal RPATHs?

Leon.

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leon Woestenberg schreef:
> After some work, I couldn't get chrpath-native nor chrpath-cross to
> deal with the target's ELF file (x86_64 host, i686 target):
> 
> ./chrpath -l /home/leon/sandbox/e520/openembedded/build/tmp/work/i686-angstrom-linux/glibc-2.5-r5/install/glibc-dbg/usr/bin/.debug/localedef
> `/home/leon/sandbox/e520/openembedded/build/tmp/work/i686-angstrom-linux/glibc-2.5-r5/install/glibc-dbg/usr/bin/.debug/localedef'
> probably isn't a 64-bit LSB-first ELF file.
> elf_open: Exec format error
> 
> although koen reported success with his host/target combo.

I suspect it will work if your bits are the same (32, 64, etc) and possibly endiannes.

> Now, for the moment, should we change insane.bbclass to indicate a
> warning instead of an error on illegal RPATHs?

IMO the question is "Do we want to subject (angstrom) users to insane.bbclass?". I don't
have an answer to that.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGMR7VMkyGM64RGpERAkVNAJ0V87eLBTSzCac+FUflc5j7RNL6wACfTdfW
6/p6Nd25aTL2KB1LIj2sPmA=
=Bjiy
-----END PGP SIGNATURE-----

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Graeme Gregory]

> A "huge gaping security hole" that requires you to download a
> malicious ipk with malicious libraries which figures out what your
> build path was, then installs those libraries there.
> 
> Or you could just download a malicious ipk which overwrites the actual
> libraries.
> 
> I don't see what's hude or gaping about this.
> 
Maybe you should rethink that before getting all sarcastic.

/home/XXX/ hmmm, thats publically writable to users.

And why do malicious libraries need to come in ipk files.

Graeme

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Graeme Gregory]

> IMO the question is "Do we want to subject (angstrom) users to insane.bbclass?". I don't
> have an answer to that.
> 
The answer is totally YES shouted out across the world as without the
errors no-one will ever fix bad packaging. Laziness is rampant in the
linux world.

Graeme

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Justin Patrin]

On 4/26/07, Graeme Gregory <dp@xora.org.uk> wrote:
>
> > A "huge gaping security hole" that requires you to download a
> > malicious ipk with malicious libraries which figures out what your
> > build path was, then installs those libraries there.
> >
> > Or you could just download a malicious ipk which overwrites the actual
> > libraries.
> >
> > I don't see what's hude or gaping about this.
> >
> Maybe you should rethink that before getting all sarcastic.
>
> /home/XXX/ hmmm, thats publically writable to users.
>

I was under the impression that /home was normally writable only by
root and the subdirs were normally only writable by the user who owns
the directory (yes, I know you can set them differently if you want).
I know I wouldn't want joe-the-user creating directory /home/justinpa
to try to confuse justinp whose home dir is /home/justinp.

> And why do malicious libraries need to come in ipk files.
>

I suppose they don't. I admit I was thinking in "Embedded" mode, which
normally means single-user to me. Still, it would have to be someone
putting files in a very specific place which should normally be only
writable by a super-user. Of course someone could use security holes
in another program to write the files, etc etc.

I'm not saying this doesn't need to be fixed, just that it seemed like
a big inconvenience for those using OE who couldn't fix the problem.
Then again it seems that someone came up with a hack at least, so....

-- 
Justin Patrin

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Graeme Gregory]

On Thu, 2007-04-26 at 15:16 -0700, Justin Patrin wrote:
> I was under the impression that /home was normally writable only by
> root and the subdirs were normally only writable by the user who owns
> the directory (yes, I know you can set them differently if you want).
> I know I wouldn't want joe-the-user creating directory /home/justinpa
> to try to confuse justinp whose home dir is /home/justinp.
> 
So someone makes an Angstrom based distro that is distributed on Ipaqs
to a school that person happens to be called John Smith (a very common
uk name). A kid at the school uses one in class and he happens to be
called John Smith and is kinda smart. Suddenly he is root.

Graeme

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Justin Patrin]

On 4/26/07, Graeme Gregory <dp@xora.org.uk> wrote:
> On Thu, 2007-04-26 at 15:16 -0700, Justin Patrin wrote:
> > I was under the impression that /home was normally writable only by
> > root and the subdirs were normally only writable by the user who owns
> > the directory (yes, I know you can set them differently if you want).
> > I know I wouldn't want joe-the-user creating directory /home/justinpa
> > to try to confuse justinp whose home dir is /home/justinp.
> >
> So someone makes an Angstrom based distro that is distributed on Ipaqs
> to a school that person happens to be called John Smith (a very common
> uk name). A kid at the school uses one in class and he happens to be
> called John Smith and is kinda smart. Suddenly he is root.
>

Sure. As I said this does need to be fixed. Sorry, I tend to get
sarcastic when responding to Koen.

-- 
Justin Patrin

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Leon Woestenberg]

Hello,

my earlier heads up was not as critical as first expected: many
packages seem to be ok, but some are not.

As the previous scanelf output always included the filename under
investigation, we had a lot of false positives.

scanelf -BF%r#F <some_file> is the way to go.

A very easy way to see if any files contain a host-side RPATH is to run:

scanelf -R -BF%r#F <some_dir> | grep <your_oe_dir>

I'll continue in bug #2140.

Regards,

Leon

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Matt Reimer]

On 4/26/07, Leon Woestenberg <leon.woestenberg@gmail.com> wrote:
> Hello all,
>
> for those of you using insane.bbclass, it will now correctly detect
> wrong RPATH's in shared libraries and fail on them.
>
> Unfortunately, as we have not fixed wrong RPATH's yet in our shared
> library handling, this will cause builds using insane.bbclass to fail.
>
> See bug #2140.
>
> I hope to be able to fix the .so RPATH stuff as well, but any help is welcomed.

IIRC, pb looked into this at one time and found that the problem was
with certain packages .pc files. So a good place to start is the check
the .pc files for those libraries that are referenced by these bogus
RPATHs.

Matt

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Rolf Leggewie]

Graeme Gregory wrote:

> Laziness is rampant in the
> linux world.

Smart people are lazy.  It is just a fact of life ;-)

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Hans Henry von Tresckow]

On 4/27/07, Rolf Leggewie <no2spam@nospam.arcornews.de> wrote:
>
> Graeme Gregory wrote:
>
> > Laziness is rampant in the
> > linux world.
>
> Smart people are lazy.  It is just a fact of life ;-)


We're not lazy, just energy efficient :)

_______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: HEADS UP: insane.bbclass will now detect and stop the build on wrong RPATHs.

[Justin Patrin]

On 4/27/07, Hans Henry von Tresckow <hvontres@gmail.com> wrote:
> On 4/27/07, Rolf Leggewie <no2spam@nospam.arcornews.de> wrote:
> >
> > Graeme Gregory wrote:
> >
> > > Laziness is rampant in the
> > > linux world.
> >
> > Smart people are lazy.  It is just a fact of life ;-)
>
>
> We're not lazy, just energy efficient :)
>

Hear hear!

-- 
Justin Patrin