51

This is not KDE related problem.

1)Some day I have idea to use special dbus-wrapper(called there console library), dbus domain(like every think) and environment variable. The application(console) checks variable to look he must create terminal. If yes, use our wrapper to create console window and set stderr, stdour, stdin to new console window pipe(single call). We can link console application with our library, replacing start function.

How it works? X Windows System will sets our variable at startup. Once user run console program and it must show output/get data, it will create console window. Programs like xterm, konsole will unset this variable. There's no matter if we ran dolphin from xterm and run console app. Xterm would have console window.

2)Actually xterm will set xterm window id, but there's matter, because other console emulator don't do that.

3)We can also provide library with provide user interface based on data types. It should looks like: get_string_match, get_number_match, get_date_match, get_dir_match, get_file_match, get_file_of_mime_match, select_action(int count, char **names), etc. Programmer may also defines collation(group of values/dialog), so user in single dialog must input a value, click on checkbox and click yes. I have started on very similar solution, but have stoped my work.

Alec wrote:No, this is a BAD, BAD idea - making binaries executable by default completely defeats the purpose of the executable bit. This allows for all sorts of bad things to happen. For example, you download a some file which gets interpreted as an executable and it deletes all your files in your home directory - just because you (maybe even accidentally) click it. (Haven't we ever seen that before?)

So no, foreign executable files should never ever be executed without a user specifically wanting to execute them.

Hi.

Looks at my project: http://slawek.lach.art.pl/secure_shell.c - v0.0.8.tar.gz

This is special command "interpreter". It would looks at script file and read information for any command to show it to user. He only trust and comprehend scripts written in special language. It is not stable yet, but idea is simple: user have problem, go to the forum and instead read full topic or copy/paste commands into terminal just click on icon. It will run my "interpreter", which read information about insecure level for each command and description or portion information from man. It can really helps if user will see:
"""rm - removes file or directory
operates on:
/etc/passwd - provide information about users"""
or
"""rm /etc/passwd - remove information about users"""

"""cp our_files /usr/bin/firefox - replace existing program"""

Of course user might click on Firefox word and read Firefox description from man .

majewsky wrote:drldk: This mockup is quite bad, because it contains irrelevant data that confuse many users, but zero information about why the user is asked for confirmation at all. Look at the dialog that comes up when you try to execute a .desktop file without executable flag.

James Tyrer wrote:The problem is that user get used to clicking through such windows without thinking.

I would say that what is needed is pop-up telling the user what to do: set the file property to executable.

This defeats the original purpose: having an easy way to execute downloaded binaries. A possible solution would to disable the "Run" button for some seconds, forcing the user to read the message. (This is how Firefox implements its "Install addon" dialog.)

Another way is to include some question that can only be answered if the user has read the message or at least knows what the message was. Like:

This file has been downloaded from the internet. Bla bla bla security issue yada yada yada. Continue?

-> Yes
-> No

When the user clicks "Yes", another dialog comes up:

What did the last dialog ask for?

-> Permission to starting a downloaded application.
-> Update the system before starting an application.
-> Confirmation to delete this file.
-> I'm not sure, let me view the dialog again.

Admittedly, I prefer the first way (disabling the "Run" button temporarily) because the second way feels like patronizing.

Very good idea! Very similar to UAC(in user case), but better. I think in second dialog we should select bad answer, so we prevent prevent some bad situation.

@Idea to ask tricky questions.

Its bad bad bad If user has downloaded that bid, it means he already/for that moment trusts/wants it. It puts user vs. OS, and OS might loose. Also asking *stupid* (from user side) question might insult him. that might lead to "Don't use kde, its stupid" flames online.


@Lachu

Does your interpreter finds stuff like:
var x1 = 'r';
var x2 = 'm';
var x3 = 'p';
eval (x1+x2+ '/etc/'+x3'+asswd');

Also it is very easy to trick such interpreter to output 10k of lines of harmless text by so hiding destroy_this_system() somewhere in the middle, so you will never spot it.

I still think this is a binary issue and as such should be handled by the various distros. For example, Debian/Ubuntu could have information stored in their .deb binary format about how to unpack .run packages and where to install them (for example, with the nVidia install script, something like ./script.sh --unpack is used to extract the packages without installing). This would also allow them to install to a standard location (as opposed to /usr/local/games in the case of ETQW) and install menu icons in the right place. The binary would be handled by Synaptic installer (or some-such)/Adept installer, which the user would be used to, and stuff like root privileges are handled in a standard way. If we continue to use ETQW as an example, then Adept/Synaptic installer would give one pop-up for the EULA and another asking them to place the CD in the tray to continue, when the script demands that.

Moreover, if standard .deb packages gained these features, they could be included in the standard package tree. This way, the developers can already state that the software is tested and safe, therefore easy to find in your standard software management program.

Not only does this allow firms like ID software to continue using .run files for distribution, which is more convenient for them, but it also allows distribution developers to configure the installation depending on their install paths and allows users to easily install the software and use it after (Because I don't want to go round every user profile to add ETQW to the menu after installing...)

This would apply to RPMs and other such binary formats as well. Ebuilds, well... they've had that flexibility for a long time now.

Lukas wrote:@Idea to ask tricky questions.

Its bad bad bad If user has downloaded that bid, it means he already/for that moment trusts/wants it. It puts user vs. OS, and OS might loose. Also asking *stupid* (from user side) question might insult him. that might lead to "Don't use kde, its stupid" flames online.


@Lachu

Does your interpreter finds stuff like:
var x1 = 'r';
var x2 = 'm';
var x3 = 'p';
eval (x1+x2+ '/etc/'+x3'+asswd');

Also it is very easy to trick such interpreter to output 10k of lines of harmless text by so hiding destroy_this_system() somewhere in the middle, so you will never spot it.

Yes, it is.
It works in this way(two step). Firstly we have run preprocessor. Preprocessor can only read files and tries to extent environments. In second step we have access to file, but the file must be locked in first step. It is very basic idea. We tries to find all dangerous think in the middle of first and second step, when we have output script(we don't change it from this moment) and before we change every think. Of course preprocessor cannot call any programs, so it's no way to send information by internet.

It's one think. As I told, it isn't stable yet, so somebody can found bug in preprocessor to trick us. That's not big matter for future. If user can open, ex. image, movies, etc., it can open not preprocessed list of commands to do.

Preprocessor is used to allow programmer gather information about system and (in future) give user a question.
It's possible situation like this(it's in pseudocode):
if $os=="linux" and $distribution="OPENSUSE" and version="10.2" then
do somethink
else
do somethink else
end
If we are using OpenSUSE, preprocessor will only send do somethink to output script. In other case preprocessor will send do somethink else to output script.
So dialog displaying user information what script like to perform are depending on os information, but tasks to do are depending too.
Best way to test my solution is download it, read examples and create your own malware. But current implementation are buggy, so program can crash in some cases.
Sorry for my English. I'm from Poland.

Actually we can do some think like that:
block "Will install our software" install follow installation:
cp -r <some directory> /
block end install
block "Will remove our software" remove follow uninstall:
rm <previously installed files>
block end uninstall

So basic user interaction are done. When input file are preproced, we asks user he like to installation/uninstall. In future it should be more tools to control scripts, like disables some condition(set is as true/false) or unconditional block.

And in second step we have only list of commands(plain). It shouldn't be transformed/translated any more. My solution needs special shell/interpreter(or some think similar ), as I told.

And I will limit list of operations before first stable version. It's also other trick. Each command/file has insecure level. We will show user highest level found in output(from preprocessor) file. User will also might filter it.

Lachu wrote:This is not KDE related problem.

1)Some day I have idea to use special dbus-wrapper(called there console library), dbus domain(like every think) and environment variable. The application(console) checks variable to look he must create terminal. If yes, use our wrapper to create console window and set stderr, stdour, stdin to new console window pipe(single call). We can link console application with our library, replacing start function.

How it works? X Windows System will sets our variable at startup. Once user run console program and it must show output/get data, it will create console window. Programs like xterm, konsole will unset this variable. There's no matter if we ran dolphin from xterm and run console app. Xterm would have console window.

2)Actually xterm will set xterm window id, but there's matter, because other console emulator don't do that.

........

Actually I've created custom solution. It was called cli2gui or cui2gui. Programer must only link program with my lib to open terminal window if needed. We can also links dynamically, by dlopen, so any installers can try to load my lib at start up.
My solution is not licensed on LGPL yet. Maybe in future I will change the license. Also, it is very GNU/Linux depend. We use init library function to handle situation when it is loaded.
With dialog about setting execute permission it will solve the main problem, but we should also think about a security.

Link to my solution: http://slawek.lach.art.pl/cli2gui-lib.tar.gz

I agree that this is annoying to new users, but I think the solution needs to be radically rethought.

Here are the key problems with most current systems:
a) They warn the user about something the user doesn't understand.
b) They annoy the user to the point where the warning/confirmation becomes routine, and thus, pointless.
c) They unnecessarily obstruct the user from doing what the user wants.

Here are the typical reactions:
a) New User: Gets confused, and or worried. New users generally won't be able to make an informed judgement, so why try to force them to? They'll probably just click something arbitrarily, which defeats the purpose.
Experienced User: Doesn't need a warning. They already know enough to only run apps they trust.

b) New User: Quickly develops a habit of clicking the most prominent button of anything that pops up. Reading the same stuff all the time stinks, so they won't notice if it's different. They'll happily launch or give permissions to anything without a second thought, which defeats the purpose.
Experienced User: Quickly figures out how to turn the whole system off, and experiences some frustration over having to do so.

c) New User: If they told the computer to run a program, then they darn well want to run it! If I want to run across a busy highway, I run the risk of getting injured... but that doesn't mean I want someone following me around and restraining me if I try. It may be stupid, but it's my decision.
Experienced User: Is disgusted by a system that tries to babysit them, and moves on.
=====================
None of these are good. We don't want to be quizzed, pestered, or have our hands held. People want to use computers, but most people don't care to learn more than the basics. I've never driven a car, but if you put me in one alone in a big open space, I could figure out how to drive it pretty quickly. That doesn't mean that I'm ready to drive on the highway; I know that if I do push the pedal, the car moves forward, but I don't know the rules of the road, and I don't know how to safely drive around others. If I get smoked by a bus, it might not be something stupid I did, but merely something I didn't know.
The reality is that there is no test to take to get an "Internet license", and people are going to blunder into things all the time - and by and large, this isn't their fault. We can't (and shouldn't) expect everyone to be knowledgeable about computers, but neither can we fully protect them with technological measures. If we do anything, we need to find a balance where we can actually help the user make the right choice, without deciding what the right choice is for them, and without assuming a certain level of knowledge.

Actually, KDE already launches .run files in a konsole window for me - however, it doesn't seem possible to run them as root (which could be a job for PolicyKit...).

KDE already has a similar feature when running a .desktop file without "executable" bit:


I suggest enhancing that window and use it for both.
The new KAuth API should work for giving root rights.

The reality, is that people are still pushing binary installers. Most proprietary games for Linux use this or generic folders. This is a reality.

I think it should warn, like apple does with downloaded files. It works great, and runs.

The way it works now is AWFUL for a new user. A text editor with a ton of garbled text. Leaving it as-is is the WORST option.