Hi,

xscreensaver tried to run 'zoom'; which resulted in this text in a
ugly yellow font on black backgroud:

"zoom: invalid option -- 'r'
Try `zoom --help' or `zoom --usage' for more information."

This can be reproduced with xscreensaver-demo; by running the last
screensaver from the list "Zoom".

This bug does _NOT_ happen when "xscreensaver-data-extra"
which provides /usr/lib/xscreensaver/zoom is also installed.

I guess renaming /usr/games/zoom to work around this is just wrong;
so this should be re-attributed to xscreensaver package (with a patch ?).

It seems fix would be that xscreensave doesn't include
/usr/games in it's path anymore.

Alexandre

Control: reassign -1 xscreensaver

Or perhaps xscreensaver-demo should only look in /usr/lib/xscreensaver...
(For the xscreensaver maintainers: the context here is that the zoom-player
package provides /usr/games/zoom, which xscreensaver attempts to use for its
Zoom screensaver if xscreensaver-data-extra isn't installed.)

Regards,

Stephen

Le samedi 5 mars 2016, 16:29:41 Stephen Kitt a écrit :

Awww, I found a duplicate:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794719

xscreensaver-data: runs /usr/bin/barcode rather than /usr/lib/xscreensaver/barcode

I'd like to help on this bug, and the 106 other ones.

Yup, this is a bit hairy, not easy to make a solution that is 100%
without patching much of the original code. However in most cases,
restricting it to /usr/lib/xscreensaver would fix the issue. There
might be some cases where a program from another package can be used,
but that can maybe be fixed by patching these individual cases in the
app-defaults file.

As upstream points out in the other report, the use of one
app-defaults file but multiple hack collection packages complicates
the issue.

Alexandre,

That would be fantastic!

Best regards,
Tormod

Having xscreensaver override and ignore the $PATH that the user passed in is a terrible idea.

But if init scripts are involved, perhaps those scripts should launch xscreensaver without /usr/games/ on $PATH.

Since we are in control of where we install the hacks
(/usr/lib/xscreensaver), it is not that bad. But it would prevent the
user from adding his own hacks somewhere random and have them launched
just by setting the $PATH. Unless he patches and rebuilds xscreensaver
himself :)

Is it not possible to specify the full path in the app-default file?
That would address above user case. Or is there other user cases I am
missing?

We do have the problem that there are name clashes. How can we handle
this if we do not ignore (alt. parts of) the $PATH? We wouldn't like
to add a namespace to all the hack binaries to avoid name clashes. And
I don't think it is realistic that the xscreensaver package takes
monopoly on names like "zoom".

Tormod

If you modify xscreensaver to not obey $PATH, you are making it do this weird, confusing, undiscoverable thing.

If you merely launch it with a different $PATH, then it's easy to know what's going on. Especially since the $PATH appears in error messages about not being able to find things.

You could do that, but just changing $PATH seems a lot simpler, and isn't going to result in merge conflicts for the rest of eternity.

Anyway, xscreensaver already prepends HACKDIR to $PATH, so this problem can only happen if HACKDIR is wrong or if the "zoom" saver is A) enabled but B) not installed.

Hey guess what, this is a problem that only exhibits itself because you took the code that I had tested and distributed, ripped half of it out, and expected the other half to continue working properly.

I am shocked -- shocked -- at this outcome.

Something you are well aware was done 8 years ago. I am truly sad --
sad -- you are still shocked.

The reasons it was done have become less important over the years, so
it might change, but in the meantime we will use another solution for
the issue at hand.

Tormod

I see the point with PATH being listed in error messages. Setting the
path or not obeying the provided one seems to me pretty much the same
(for locating hacks), so I am fine with that too.

But let me be clear, I am only talking about the part "let's start the
hack with name X". For running helpers etc it would be nice to have a
reasonable PATH so xscreensaver-get-images & friends can be found
without that we force full paths on them, or clumsy soft links in
/usr/lib/xscreensaver - this would get messy since "friends" can
involve a lot of dependencies. Is it not possible to say, when X is a
name in preferences that has no path, to run /usr/lib/xscreensaver/X
but with full (unmodified) PATH?

I meant for the users if they want to add their own hack. I did not
mean we should add full path to the hacks we ship in
/usr/lib/xscreensaver. Definitely would like to avoid patching the
app-defaults more than necessary :)

Tormod

Sorry, I don't understand what you're proposing. Can you give some examples?

Why do you object to "just set $PATH in whatever script launched xscreensaver"? That seems simple to me.

I don't object to setting PATH, it seems simple and it would help
against the name clashes in /usr/games like zoom. I am just thinking
of possible clashes with other programs in /usr/bin as well. There are
like 10000 packages in Debian and new ones coming all the time, so it
can make sense to "protect" the screensaver from conflicts. Because
some hacks execute utilities we are placing in /usr/bin, for instance
xscreensaver-get-image (and I think some of these call other utilities
also), a modified PATH will still have to include /usr/bin. Since we
are placing all hacks into /usr/lib/xscreensaver, we can also restrict
the spawning of hacks to this path. Then PATH can be left unmodified,
for whatever the hacks need to execute. And in the few cases the user
wants to add another executable to his configuration file, he will
just have to provide the full path to it. We would simply check
hack->command for a starting slash and if none, prepend
/usr/lib/xscreensaver. So if the configuration file says "zoom -bla"
we would run "/usr/lib/xscreensaver/zoom -bla". If it says
"/usr/games/zoom -bla" we would run that. It would be more restrictive
but also more fail proof.

Tormod

I still think the root of the problem here is that the "zoom" xscreensaver hack is marked as enabled in the .ad file, but it is not actually installed. So the .ad file is wrong. Correcting it would fix this. I suppose it would be possible to do that in a post-install script on the xscreensaver sub-packages.

It would also work to make every entry in the .ad file be an absolute path instead of relative.

But I don't like the idea of forcing entries in the .ad file that are not absolute paths to only run from a hardcoded directory.

I am also not so fond of the hardcoding. If the directory name could
be overrun by a user setting it would have very acceptable though.

On the other hand, we don't want to mess with users' or
administrators' configuration files. Granted, if the system .ad is
unmodified by the administrator, we can change it or modify by a
script, but if the user has run xscreensaver and has his own
configuration file we are not gonna touch it. "Breaking" it by not
allowing all possible entries to run, would be more acceptable. We are
after all tying everything down and installing the hacks to a very
defined location. I think it is important that the stock setup works
without issues, even if it means the rare experimental user gets one
more hurdle for doing very specific customizations. Without turning it
into gnome-screensaver :)

Tormod

I'm not going to change anything here. Xscreensaver is working as designed. The problem being experienced is because the system it is running on is misconfigured.

Specifically, xscreensaver is only halfway installed; and it is configured to run modes that the half-install does not include.

Fix either of those system misconfigurations to solve this.

Yes, I expect we have to make a Debian-specific kludge here. Thanks
for your input anyway, Jamie.

Tormod

Le jeudi 7 avril 2016, 22:45:20 Tormod Volden a écrit :

I said so right before I got this mission with a 6 hours daily commute :-)

I'll come back at this at soon as it's done (or I'm done with job).

(╯°□°）╯︵ ┻━┻

Last year proliferation of the other zoom on user devices has turned
the "halfway installed" XScreenSaver into a malware which randomly
starts the proprietary closed-source app while users are AFK.

I would suggest to bump the Severity of this issue.