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

DoneSubmitted by Bengt Richter.
Details
7 participants
  • Bengt Richter
  • Brett Gilio
  • Julien Lepiller
  • Tobias Geerinckx-Rice
  • Mark HWeaver
  • Ricardo Wurmus
  • zimoun
Owner
unassigned
Severity
normal
B
B
Bengt Richter wrote on 29 Nov 2019 08:59
(name . New-Bug)(address . bug-guix@gnu.org)(name . Mark HWeaver)(address . mhw@netris.org)
20191129075938.GA55971@PhantoNv4ArchGx.localdomain
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 icecatand let it load a "theme", but I am not sure some didn'talso 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
Toggle snippet (24 lines) 1 x '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng' 1 x '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng' 97 x '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng' 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng' 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng' 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng' 1 x '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng' 34143 x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme 1 x '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng' 62 x '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook 1 x '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng' 1 x '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng' 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng' 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng' 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng' 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng' 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng' 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng' 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng' 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'

-- Regards,Bengt Richter
R
R
Ricardo Wurmus wrote on 29 Nov 2019 10:49
(name . Bengt Richter)(address . bokr@bokr.com)(address . 38422@debbugs.gnu.org)
87r21r9fn1.fsf@elephly.net
Bengt Richter <bokr@bokr.com> writes:
Toggle quote (26 lines)> $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less> --8<---------------cut here---------------start------------->8---> 1 x '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'> 1 x '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng'> 97 x '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme> 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng'> 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng'> 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng'> 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng'> 1 x '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng'> 34143 x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme> 1 x '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng'> 62 x '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook> 1 x '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng'> 1 x '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng'> 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng'> 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng'> 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng'> 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng'> 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng'> 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng'> 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng'> 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'>> --8<---------------cut here---------------end--------------->8---
Maybe I’m missing something, but none of the above are PNGs.Most of them are executables, others are directories, so having themexecutable is expected.
Did I misunderstand?
-- Ricardo
Z
Z
zimoun wrote on 29 Nov 2019 11:59
(name . Ricardo Wurmus)(address . rekado@elephly.net)
CAJ3okZ21-vxmBFrHp=26Cz7VMa+Z-e=i5o1wB8oGsE+96-M3pg@mail.gmail.com
Hi,
On Fri, 29 Nov 2019 at 11:43, Ricardo Wurmus <rekado@elephly.net> wrote:
Toggle quote (4 lines)> 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.
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
T
T
Tobias Geerinckx-Rice wrote on 29 Nov 2019 12:28
87r21q9b1h.fsf@nckx
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 写道:
Toggle quote (4 lines)> Is this zero-day stuff with a nasty somewhere, waiting for > referencing> by another nasty, or am I being paranoid?
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 写道:
Toggle quote (57 lines)> Bengt Richter <bokr@bokr.com> writes:>>> $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a >> %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less>> --8<---------------cut >> here---------------start------------->8--->> 1 x >> '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'>> 1 x >> '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng'>> 97 x >> '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme>> 1 x >> '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng'>> 1 x >> '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng'>> 1 x >> '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng'>> 1 x >> '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng'>> 1 x >> '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng'>> 34143 x >> '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme>> 1 x >> '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng'>> 62 x >> '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook>> 1 x >> '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng'>> 1 x >> '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng'>> 1 x >> '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng'>> 1 x >> '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng'>> 1 x >> '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng'>> 1 x >> '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng'>> 1 x >> '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng'>> 1 x >> '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng'>> 1 x >> '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng'>> 1 x >> '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'>>>> --8<---------------cut >> here---------------end--------------->8--->> 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.
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:
Toggle quote (3 lines)> 34143 x > '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme
i.e. 34143 executable '*png' files in that directory alone.
Kind regards,
T G-R
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl3hANoACgkQ2Imw8BjFSTyoQw/8DY28FMGC7nexg4kH6CfHc7IQS3YoWG6EosQfagSQdKF0dZlWtQhuDLLHl3e3yhXI03Aumu+mI/TkZcpNmUAWmkeuWUqlqb3ZRjQvbLUJaztRj23bb/ahVzQiWGfHM9GejPLMDg70947V/SQPYcRo4MYf9lL5n2rEL2DvagSaTU6JfeOXbw3Xkchz+AhyLvAPqt+8G8YIGSs7cyqYx/id+Gwal6rqs6zae0jD7dw/rIAOjqiDiCUPvGGDU0saWXxkNi3YRpLsUExBj+RkCs8ZqATHq4/nB0a2aWbx4P3VjDlnZB+gAwLw4EB9CidFl9QfiF6JzYtrYDuW7vN2mks/2hJjMNwrHXubeA8P4oMybOL20R43sGnBBy6JWKi/S7toUAy2B4FV91d2GD2aqk62rScyMYN6tVFHmZaGA1s2hWAtrMns1xGz2ERqXWsZd6DookQ9ezZlpw2M+WWLzKA4D8whZWE2WNIfVCEQw752liWScawQMJyJ3ahkZzOeNZs001esxdyoorYrZLRVHvAJ9SQrLXEnKNf7vQOR/WztKRM3UQlyyuQr4pFQagSRmHGwBKfKJ7+UzvOdRPXdkCzwI9TpS7sG6mtWgO2wF6AfUMfJhMnHmLw532U7tQG9DltBQNx/CDt9zgp4JI9skaSTVlJs+S+hBiWVAebE6AqMvyw==aFZ0-----END PGP SIGNATURE-----
M
M
Mark HWeaver wrote on 29 Nov 2019 13:20
Re: .png files in /gnu/store with executable permissions (555)
(name . Bengt Richter)(address . bokr@bokr.com)(address . 38422@debbugs.gnu.org)
878sny6fgr.fsf@netris.org
Hi Bengt,
Bengt Richter <bokr@bokr.com> wrote:
Toggle quote (7 lines)> 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 havesufficient permissions to modify /gnu/store. Installing a theme oraddon in IceCat, or changing its configuration, modifies files in your~/.mozilla, not /gnu/store.
Toggle quote (4 lines)> 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 onmy system. Some of the *.png files are incorrectly given executablepermissions within the upstream source tarball itself. I guess it'sprobably the same issue with moka-icon-theme and faba-icon-theme, sinceI 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" areactually programs whose name ends with "png", so they *should* beexecutable. The files in /gnu/store/.links that end with "png" are justrandom chance, because the file names themselves are hashes.
Toggle quote (3 lines)> 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 hereto be concerned about, just some minor sloppiness by 3 upstreams.
Toggle quote (2 lines)> What is the safe way to detoxify this mess?
The proper solution is to send bug reports to the upstream developers ofdocbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to fixthe permissions of the *.png files in their source tarballs.
Toggle quote (2 lines)> I know I shouldn't directly chmod anything in store, right?
Right, *never* modify files in /gnu/store directly.
Toggle quote (2 lines)> The icecat discussion got moved to mozilla,
Which discussion are you referring to?
Thanks, Mark
B
B
Bengt Richter wrote on 29 Nov 2019 13:22
Re: bug#38422: .png files in /gnu/store with executable permissions (555)
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 38422@debbugs.gnu.org)
20191129122236.GA67682@PhantoNv4ArchGx.localdomain
Hi Ricardo,
On +2019-11-29 10:49:06 +0100, Ricardo Wurmus wrote:
Toggle quote (36 lines)> > Bengt Richter <bokr@bokr.com> writes:> > > $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less> > --8<---------------cut here---------------start------------->8---> > 1 x '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'> > 1 x '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng'> > 97 x '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme> > 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng'> > 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng'> > 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng'> > 1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng'> > 1 x '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng'> > 34143 x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme> > 1 x '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng'> > 62 x '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook> > 1 x '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng'> > 1 x '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng'> > 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng'> > 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng'> > 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng'> > 1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng'> > 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng'> > 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng'> > 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng'> > 1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'> >> > --8<---------------cut here---------------end--------------->8---> > 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?>
No, you just didn't see it ;-)┌───────────────────────────────────────────────────────────────────────────────────────────────┐│ Sorry I didn't highlight well enough that I had trimmed off the full paths that ended in .png ││ in what you snipped out above the above (see box below): │└───────────────────────────────────────────────────────────────────────────────────────────────┘
--8<----(the part you snipped out)-----------cut here---------------start------------->8---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 icecatand let it load a "theme", but I am not sure some didn'talso 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 :)--8<----(the part you snipped out)-----------cut here---------------end--------------->8---

Note the cut -d '-' etc from above
Toggle snippet (3 lines)> > $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less
I thought the 34143 moka-icon-theme items looked especially iffy, being so many:
Toggle snippet (3 lines)> > 34143 x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme
So let's not cut that tail and just grab some of those moka-icon-theme items full length:$ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|grep moka-icon-theme|head
Toggle snippet (12 lines)555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-insync-synced.png'555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-synchronizing.png'555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-insync-synced-callbacks-active.png'555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-insync-syncing.png'555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-dropbox-uptodate.png'555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-readonly.png'555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-important.png'555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-danger.png'555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-web.png'555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-symbolic-link.png'
Some executables ending in png are legit, like conversion programs from something to .png format.
Toggle quote (4 lines)> -- > Ricardo>
PS. Thinking about it, I'm pretty sure I used normal guix install ... yes:
--8<----(555s were in source tarball)-----------cut here---------------start------------->8---$ guix package -I|grep -i mokamoka-icon-theme 5.4.0 out /gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0$ mkdir ~/my-roots$ guix build -r ~/my-roots/moka -S moka-icon-themesubstitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%67.4 MB will be downloaded: /gnu/store/vd3l2qbmdw0i9v9knqjm3q42sfwli2nl-moka-icon-theme-5.4.0.tar.gzsubstituting /gnu/store/vd3l2qbmdw0i9v9knqjm3q42sfwli2nl-moka-icon-theme-5.4.0.tar.gz...downloading from https://ci.guix.gnu.org/nar/vd3l2qbmdw0i9v9knqjm3q42sfwli2nl-moka-icon-theme-5.4.0.tar.gz... moka-icon-theme-5.4.0.tar.gz 64.3MiB 1.5MiB/s 00:44 [##################] 100.0%
/gnu/store/vd3l2qbmdw0i9v9knqjm3q42sfwli2nl-moka-icon-theme-5.4.0.tar.gz$ lsc ~/my-roots/* 72 2019-11-29 03:53:27 [@] /home/bokr/my-roots/moka -> /gnu/store/vd3l2qbmdw0i9v9knqjm3q42sfwli2nl-moka-icon-theme-5.4.0.tar.gz$ tar -tzvf ~/my-roots/moka|egrep -m5 'png$'lrwxrwxrwx root/root 0 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/exit.png -> system-log-out.pnglrwxrwxrwx root/root 0 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/gnome-lockscreen.png -> system-lock-screen.pnglrwxrwxrwx root/root 0 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/gnome-logout.png -> system-log-out.pnglrwxrwxrwx root/root 0 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/gnome-run.png -> system-run.pnglrwxrwxrwx root/root 0 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/gnome-session-reboot.png -> system-restart.png
Oops, those were links, let's try again:
$ tar -tzvf ~/my-roots/moka|egrep -m5 '^[^l].*png$'-rwxrwxr-x root/root 633 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/system-lock-screen.png-rwxrwxr-x root/root 537 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/system-log-out.png-rwxrwxr-x root/root 554 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/system-restart.png-rwxrwxr-x root/root 549 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/system-run.png-rwxrwxr-x root/root 544 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/system-shutdown.png--8<----(555s were in source tarball)-----------cut here---------------end--------------->8---
-- Regards,Bengt Richter
B
B
Bengt Richter wrote on 29 Nov 2019 16:03
Re: .png files in /gnu/store with executable permissions (555)
(name . Mark HWeaver)(address . mhw@netris.org)(address . 38422@debbugs.gnu.org)
20191129150329.GA80736@PhantoNv4ArchGx.localdomain
Hi Mark.
On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
Toggle quote (15 lines)> Hi Bengt,> > Bengt Richter <bokr@bokr.com> 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 probablywhile you were writing this :) There I extracted someguix build -S tarball content and showed that that was the perm source.
Toggle quote (9 lines)> > 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.
Toggle quote (5 lines)> > 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 curioushow many legit executables ended in png.
Toggle quote (7 lines)> > > 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 infoin some tricky malware, so anomalies in the same kind of file triggeredthe question of whether it could be accidentally on purpose ;-/
Toggle quote (6 lines)> > 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 niceto have a guix show --verbose that would show bug reporting info :)
Toggle quote (9 lines)> > 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?>
Toggle quote (3 lines)> Thanks,> Mark
-- Regards,Bengt Richter
M
M
Mark HWeaver wrote on 30 Nov 2019 05:08
Re: bug#38422: .png files in /gnu/store with executable permissions (555)
(name . Bengt Richter)(address . bokr@bokr.com)(address . 38422@debbugs.gnu.org)
871rtq57kd.fsf@netris.org
Hi Bengt,
Bengt Richter <bokr@bokr.com> writes:
Toggle quote (7 lines)> On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:>> 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?
No.
Toggle quote (3 lines)> "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 :)
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 thenwe'd need to add it to each of our 10K+ packages. It would also be anadditional job to do when adding new packages. I'm not sure it's worthall that work. We already record the home page, and from there it'susually 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 problemthat should be fixed upstream.
What do you think?
Regards, Mark
B
B
Brett Gilio wrote on 30 Nov 2019 05:24
(name . Mark HWeaver)(address . mhw@netris.org)
87sgm6t2i6.fsf@posteo.net
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (12 lines)> [...] 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>>>
Agreed 100% with Mark.
-- Brett M. Giliohttps://git.sr.ht/~brettgilio/
J
J
Julien Lepiller wrote on 30 Nov 2019 08:45
(address . 38422@debbugs.gnu.org)
FCCE8805-6725-425D-99DE-4CCD2E00DCF4@lepiller.eu
Le 30 novembre 2019 05:08:55 GMT+01:00, Mark H Weaver <mhw@netris.org> a écrit :
Toggle quote (33 lines)>Hi Bengt,>>Bengt Richter <bokr@bokr.com> writes:>>> On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:>>> 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?>>No.>>> "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 :)>>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
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 :)
B
B
Bengt Richter wrote on 30 Nov 2019 21:07
(name . Julien Lepiller)(address . julien@lepiller.eu)
20191130200748.GA2661@PhantoNv4ArchGx.localdomain
On +2019-11-30 08:45:09 +0100, Julien Lepiller wrote:
Toggle quote (19 lines)> Le 30 novembre 2019 05:08:55 GMT+01:00, Mark H Weaver <mhw@netris.org> a écrit : > >Hi Bengt, > > > >Bengt Richter <bokr@bokr.com> writes: > > > >> On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote: > >>> 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? > > > >No. > > > >> "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 :) > >
┌───────────────────────────────────────────────────────────────────────┐ │ > >It would be nice, but it would also be an enormous amount of work. │ └───────────────────────────────────────────────────────────────────────┘
Toggle quote (9 lines)> >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. > >
┌──────────────────────────┐ │ I think you are right :) │ ├──────────────────────────┤ │ > >What do you think? │ │ > > │ │ > > Regards, │ │ > > Mark │ └──────────────────────────┘
Toggle quote (1 lines)>
┌──────────────────────────────────────────────────────────────┐ │ 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
Z
Z
zimoun wrote on 2 Dec 2019 16:20
(name . Bengt Richter)(address . bokr@bokr.com)
CAJ3okZ0ze6xgLKF8Ss6s4nxSn4Xh39KO7ooF7qO=juq6yakNQw@mail.gmail.com
On Sat, 30 Nov 2019 at 21:09, Bengt Richter <bokr@bokr.com> wrote:
Toggle quote (4 lines)> 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?
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 oneneeds some Guix knowledge to correctly find what one is looking for.Debian has more friendly entry point: the package Tracker [3]. And thewebpage [4] should be improved to report our bug etc. (as Debian isdoing).
(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
Z
Z
zimoun wrote on 22 Jan 2020 01:22
Bug status? '.png' files with executable permissions
CAJ3okZ2ZAs+Cf0k29Aafk-LUG4FTU=wtzEJmk8pqVJ==SQ7eNQ@mail.gmail.com
Dear Bengt,
The bug report [1] points out files with unexpected permission; basedon extension filename.
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38422

It is not an security issue or the Guix packager did not carefullycheck the validity of these files.
If you are security paranoid, you *have to* check by yourself all thefiles using "guix build -S" because in paranoid mode you cannot trustGuix 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, andmoka-icon-theme comes with unexpected .png file permission.

On the long term, I am not convinced that adding automatic check andpermission change based on filename extension would really add QualityAssurance. Because we are speaking about quality, not security.

I am inclined to close this bug. What do you think?
All the best,simon
Z
Z
zimoun wrote on 22 Jan 2020 01:31
CAJ3okZ3fOHk-SHHq8xpKrDbNY-EfRLRKG5iPMORu60z5sQK1xw@mail.gmail.com
tags 38422 notabugquit
B
B
Bengt Richter wrote on 22 Jan 2020 03:28
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 38422@debbugs.gnu.org)
20200122022830.GA22138@LionPure
Hi zimoun,
On +2020-01-22 01:22:45 +0100, zimoun wrote:
Toggle quote (35 lines)> 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
Ok with me to close, thanks.
-- Regards,Bengt Richter
Z
Z
zimoun wrote on 27 Jan 2020 20:55
(address . 38422-done@debbugs.gnu.org)
CAJ3okZ2WMr5Ha0wz9S=v2MY3oqCu9h+i3G2r8n77zCh_iyMxsg@mail.gmail.com
close 38422stop
Closed
?
Your comment

This issue is archived.

To comment on this conversation send email to 38422@debbugs.gnu.org