Ticket #207 (closed bug: fixed)

Opened 5 years ago

Last modified 3 years ago

Unsecure RUNPATHS in parrot 0.90

Reported by: lu_zero Owned by: jkeenan
Priority: normal Milestone:
Component: install Version: 0.9.0
Severity: low Keywords:
Cc: Language:
Patch status: Platform:

Description

Gentoo Portage Q/A checks found this issue:

  • QA Notice: The following files contain insecure RUNPATH's
  • /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/bin/perl6
  • /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/bin/parrot_config
  • /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/bin/pbc_disassemble
  • /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/bin/pbc_to_exe
  • /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/gdbmhash.so
  • /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/digest_group.so
  • /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/perl6_group.so
  • /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/subproxy.so
  • /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/dynlexpad.so
  • /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/rational.so

Maybe the could be addressed sooner or later

Change History

  Changed 5 years ago by doughera

For the paths in parrot_config and pbc_to_exe, see ticket TT #208. For a patch to fix the path in pbc_disassemble, see TT #209.

  Changed 5 years ago by jkeenan

  • component changed from none to install

  Changed 5 years ago by wayland

For the dynext ones, see TT #540

follow-up: ↓ 5   Changed 3 years ago by jkeenan

Is there any way someone other than a Gentoo user would be able to either (a) evaluate the items listed in the OP; or (b) identify which items have been resolved?

Thank you very much.

kid51

in reply to: ↑ 4 ; follow-up: ↓ 6   Changed 3 years ago by doughera

Replying to jkeenan:

Is there any way someone other than a Gentoo user would be able to either (a) evaluate the items listed in the OP; or (b) identify which items have been resolved?

On Linux, you can use chrpath -l to check. I think they are all ok now, and you can close the ticket.

in reply to: ↑ 5 ; follow-up: ↓ 7   Changed 3 years ago by jkeenan

  • owner set to jkeenan
  • status changed from new to assigned

Replying to doughera:

items listed in the OP; or (b) identify which items have been resolved? On Linux, you can use chrpath -l to check. I think they are all ok now, and you can close the ticket.

Never having used chrpath before, I had to install its Debian package to do this. I checked on all the executables and all the .so files. In the case of the executables, the output always looked like this:

$ chrpath -l parrot
parrot: RPATH=/home/jimk/gitwork/parrot/blib/lib

In the case of the .so files, the output always looked like this:

$ chrpath -l ./blib/lib/libparrot.so.3.0.0
./blib/lib/libparrot.so.3.0.0: no rpath or runpath tag found.
$ $ chrpath -l runtime/parrot/dynext/bit_ops.so
runtime/parrot/dynext/bit_ops.so: no rpath or runpath tag found.

Is that the expected output? Does it suffice to close the ticket?

Thank you very much.

kid51

in reply to: ↑ 6   Changed 3 years ago by doughera

  • status changed from assigned to closed
  • resolution set to fixed

Replying to jkeenan:

Never having used chrpath before, I had to install its Debian package to do this. I checked on all the executables and all the .so files. In the case of the executables, the output always looked like this:

> $ chrpath -l parrot
> parrot: RPATH=/home/jimk/gitwork/parrot/blib/lib

In the case of the .so files, the output always looked like this:

> $ chrpath -l ./blib/lib/libparrot.so.3.0.0
> ./blib/lib/libparrot.so.3.0.0: no rpath or runpath tag found.
> $ $ chrpath -l runtime/parrot/dynext/bit_ops.so
> runtime/parrot/dynext/bit_ops.so: no rpath or runpath tag found.

Is that the expected output? Does it suffice to close the ticket?

To be absolutely thoroughly paranoid, you would have to run 'make install' and run that command on the installed versions, not on the versions in the build directory. However, parrot doesn't actually build 'installable' versions of dynext/*.so anyway, so it wouldn't matter.

I've closed the ticket.

Note: See TracTickets for help on using tickets.