.png files in /gnu/store with executable permissions (555)

Hi Guix,

I was wanting to check on some executable files in the store,

and happened to see some executable .png files ;-/

I suspect they came in when I was playing with icecat

and let it load a "theme", but I am not sure some didn't

also happen trying to get firefox radio buttons to work ;-/

Anyway, does anyone else get 555 permissions on files like these?

These are all *.png files with 555 permissons, but I trimmed back to see common prefixes.

Obviously the moka-con-theme was most of it, but also faba and docbook look iffy.

Is this zero-day stuff with a nasty somewhere, waiting for referencing by another nasty, or am I being paranoid?

What is the safe way to detoxify this mess? I know I shouldn't directly chmod anything in store, right?

The icecat discussion got moved to mozilla, but in case someone else did whatever I did,

I thought I'd post a heads-up here.

I'll try to cc Mark :)

$ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less

--

Regards,

Bengt Richter

Bengt Richter <bokr@bokr.com> writes:

Maybe I’m missing something, but none of the above are PNGs.

Most of them are executables, others are directories, so having them

executable is expected.

Did I misunderstand?

--

Ricardo

Hi,

On Fri, 29 Nov 2019 at 11:43, Ricardo Wurmus <rekado@elephly.net> wrote:

I am not sure to understand the issue but for example:

find /gnu/store/ -type f -perm /111 -iname '*.png' -print

returns this file:

/gnu/store/xj7kn8vw1nkcg7qpl3491b831p88i9wn-python-coverage-4.5.3/lib/python3.7/site-packages/coverage/htmlfiles/keybd_open.png

Hope that helps,

simon

Bengt, Ricardo,

I see similar results here with ‘guix install moka-icon-theme’,

and I'm sure the rest of my (and everyone's) store is full of

misperm'd files too. It's kind of generally known.

This seems to be particularly common in Meson packages: for some

reason, Meson installs everything as executable by default.

Bengt Richter ???

What's the threat model there? Respectfully, I think you might

be, but maybe I'm naive…

Otherwise I consider this a merely cosmetic issue, but we still

welcome fixes for those!

Checking whether Meson behaves differently on other distributions

would be a good start.

Ricardo Wurmus ???

Bengt's clever pipeline tallies the number of executable *png

files in each top-level store directory. It does not include

directories.

It's true that the '*png' above should be replaced with '*.png',

but these /bin files are just the very noisy outliers.

The meat is in:

i.e. 34143 executable '*png' files in that directory alone.

Kind regards,

T G-R

Hi Bengt,

Bengt Richter <bokr@bokr.com> wrote:

Certainly not. Unless you ran icecat as root, it would not have

sufficient permissions to modify /gnu/store. Installing a theme or

addon in IceCat, or changing its configuration, modifies files in your

~/.mozilla, not /gnu/store.

I looked at docbook-xsl-1.79.1, since I happen to have it installed on

my system. Some of the *.png files are incorrectly given executable

permissions within the upstream source tarball itself. I guess it's

probably the same issue with moka-icon-theme and faba-icon-theme, since

I don't see anything in our package code that would have done it.

Most of the entries in your list that end with "png" but not ".png" are

actually programs whose name ends with "png", so they *should* be

executable. The files in /gnu/store/.links that end with "png" are just

random chance, because the file names themselves are hashes.

I think you're being paranoid in this case. I don't see anything here

to be concerned about, just some minor sloppiness by 3 upstreams.

The proper solution is to send bug reports to the upstream developers of

docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to fix

the permissions of the *.png files in their source tarballs.

Right, *never* modify files in /gnu/store directly.

Which discussion are you referring to?

Thanks,

Mark

Hi Mark.

On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:

Yes, d'oh ;-) I was writing the "PS." in my reply to Ricardo probably

while you were writing this :) There I extracted some

guix build -S tarball content and showed that that was the perm source.

Yes, I found the bad perms in the tarball likewise.

Yeah, I realized. Could have done a cleaner job, but I was also curious

how many legit executables ended in png.

IIRC I did read of jpeg images being used to obfuscate call-home info

in some tricky malware, so anomalies in the same kind of file triggered

the question of whether it could be accidentally on purpose ;-/

That I haven't done. Is there a standard way to do it?

"guix show moka-icon-theme" tells me homepage, but it would be nice

to have a guix show --verbose that would show bug reporting info :)

Sorry, wrong zilla ;-p

--

Regards,

Bengt Richter

Hi Bengt,

Bengt Richter <bokr@bokr.com> writes:

No.

It would be nice, but it would also be an enormous amount of work.

First we'd need to devise a way to represent that information, and then

we'd need to add it to each of our 10K+ packages. It would also be an

additional job to do when adding new packages. I'm not sure it's worth

all that work. We already record the home page, and from there it's

usually not much work to find how to report bugs. In cases where it

_is_ difficult to find out how to report bugs, that's arguably a problem

that should be fixed upstream.

What do you think?

Regards,

Mark

Mark H Weaver <mhw@netris.org> writes:

Agreed 100% with Mark.

--

Brett M. Gilio

Le 30 novembre 2019 05:08:55 GMT+01:00, Mark H Weaver <mhw@netris.org> a écrit :

Also, we should not encourage people to report bugs upstream directly. We have to evaluate whether the bug is on our side or theirs first to not drown them in useless bug reports :)

On +2019-11-30 08:45:09 +0100, Julien Lepiller wrote:

?????????????????????????????????????????????????????????????????????????

? > >It would be nice, but it would also be an enormous amount of work. ?

?????????????????????????????????????????????????????????????????????????

????????????????????????????

? I think you are right :) ?

????????????????????????????

? > >What do you think? ?

? > > ?

? > > Regards, ?

? > > Mark ?

????????????????????????????

????????????????????????????????????????????????????????????????

? I think you are also right -- I withdraw my suggestion :) ?

????????????????????????????????????????????????????????????????

? > Also, we should not encourage people to report bugs ?

? upstream directly. We have to evaluate whether the bug is on ?

? our side or theirs first to not drown them in useless bug ?

? reports :) ?

????????????????????????????????????????????????????????????????

Hm, this seems like it could be important for good relations with upstream?

Should there be an official _distilled and filtered-for-upstream_

git bug repo that guix developers populate and upstream devs

(and anyone) can pull and grep the log of for their projects?

I could imagine (hallucinate ? :) some benfits:

1. First of all, we can all determine easily if there has been

an "official" report from guix to upstream, to avoid even bothering

guix developers.

2. If upstream devs know reports have been considered important enough

by guix developers to be put in the repo, they might pay more attention :)

There is a lot of tl;dr discussion in many bug-reporting logs, so upstream

would probably appreciate having curated reports.

3. The log would be a record. Commit hashes would become precise references.

4. To keep the main bug info stream clear of speculative chatty stuff

(though this sometimes contains critical clues, and belongs somewhere)

the repo could contain (per major upstream?) files for commentary or

miscellaneous that guix devs might want to pass on, but not clutter

the main report with. Of course urls into bugzilla etc can be useful

as concise see-further refs. All misc stuff optional.

4. The work flow for developers already exists for accepting things

into the guix package repo, so no major new patterns for everyone to learn.

5. Anyone interested could clone the repo and pull to it for "guix-official"

bug reporting status.

WDYT?

--

Regards,

Bengt Richter

On Sat, 30 Nov 2019 at 21:09, Bengt Richter <bokr@bokr.com> wrote:

The Guix bug database is public and can be browsed for example here

[1] or [2]. Yes, it is not friendly for upstream developer and one

needs some Guix knowledge to correctly find what one is looking for.

Debian has more friendly entry point: the package Tracker [3]. And the

webpage [4] should be improved to report our bug etc. (as Debian is

doing).

(Note that the Guix-HPC search interface is better but currently down.)

[1] http://issues.guix.gnu.org/

[2] https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix;max-bugs=100;base-order=1;bug-rev=1

[3] https://tracker.debian.org/pkg/gmsh

[4] http://guix.gnu.org/packages/gmsh-2.16.0/

All the best,

simon

Dear Bengt,

The bug report [1] points out files with unexpected permission; based

on extension filename.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38422

It is not an security issue or the Guix packager did not carefully

check the validity of these files.

If you are security paranoid, you *have to* check by yourself all the

files using "guix build -S" because in paranoid mode you cannot trust

Guix packagers (and Guix committers neither).

In normal mode, 2 options:

a- propose a patch to change the permission for each offending package

b- report upstream

Well, at least these 3 packages docbook-xsl, faba-icon-theme, and

moka-icon-theme comes with unexpected .png file permission.

On the long term, I am not convinced that adding automatic check and

permission change based on filename extension would really add Quality

Assurance. Because we are speaking about quality, not security.

I am inclined to close this bug. What do you think?

All the best,

simon

tags 38422 notabug

quit

Hi zimoun,

On +2020-01-22 01:22:45 +0100, zimoun wrote:

Ok with me to close, thanks.

--

Regards,

Bengt Richter

close 38422

stop