[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38422: .png files in /gnu/store with executable permissions (555)
From: |
Bengt Richter |
Subject: |
bug#38422: .png files in /gnu/store with executable permissions (555) |
Date: |
Fri, 29 Nov 2019 07:03:29 -0800 |
User-agent: |
Mutt/1.12.2 (2019-09-21) |
Hi Mark.
On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
> Hi Bengt,
>
> Bengt Richter <address@hidden> wrote:
> > 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 ;-/
>
> 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.
>
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.
> > 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.
>
> 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.
Yes, I found the bad perms in the tarball likewise.
>
> 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.
Yeah, I realized. Could have done a cleaner job, but I was also curious
how many legit executables ended in png.
>
> > Is this zero-day stuff with a nasty somewhere, waiting for referencing
> > by another nasty, or am I being paranoid?
>
> 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.
>
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 ;-/
> > What is the safe way to detoxify this mess?
>
> 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.
>
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 :)
> > I know I shouldn't directly chmod anything in store, right?
>
> Right, *never* modify files in /gnu/store directly.
>
> > The icecat discussion got moved to mozilla,
>
> Which discussion are you referring to?
>
Sorry, wrong zilla ;-p
https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00686.html
> Thanks,
> Mark
--
Regards,
Bengt Richter