MX-17.1-RC1 Release Candidate Feedback

[skidoo]

How did you spot check?

Said differently: I did not test each and every tool displayed in MX Tools UI. Of those I did check, I consistently found

-- help button does NOT invoke a root-permissioned instance of mx-viewer

-- clicking the hyperlink displayed within the tool's "About" dialog DOES invoke a root-permissioned web browser instance

[dolphin_oracle]

How did you spot check?

Said differently: I did not test each and every tool displayed in MX Tools UI. Of those I did check, I consistently found

-- help button does NOT invoke a root-permissioned instance of mx-viewer

-- clicking the hyperlink displayed within the tool's "About" dialog DOES invoke a root-permissioned web browser instance

gotcha, thanks.

[skidoo]

re: the "tilde characters display as dashes" issue

Viewed from a browser session under windows, I now see tilde characters displayed within in my earlier post.
Shrug. Chalk it up to "due something within the current packaged-for-linux firefox version".

[dolphin_oracle]

re: the "tilde characters display as dashes" issue

Viewed from a browser session under windows, I now see tilde characters displayed within in my earlier post.
Shrug. Chalk it up to "due something within the current packaged-for-linux firefox version".

I wondered what was going on...I could see tilda's but then I was starting to question if there were supposed to be more tildas than I was seeing

***edit*** I was using chrome with the above comments. switched to firefox and yep, tildas are dash marks instead.

anyone got an idea on that one?

test: these are tildas ~~~~~~~

Code: Select all

more tildas ~~~~~~~

tildas in code blocks seem to still be tildas, but not in the regular message space. All look ok in chrome. Unchecking the "allow pages to choose their own fonts" makes it look correct again but of course overrides site fonts, so my question is do we have a font problem on the forum?

[Adrian]

-- clicking the hyperlink displayed within the tool's "About" dialog DOES invoke a root-permissioned web browser instance

That's pretty much unavoidable for links, links are handled by the operating system, it's not the program that decides how they are opened, like for example if you have a link in a root terminal, try this:
1. open xfce4-terminal as root with "sudo xfce4-terminal"
2. type a link "echo https://mxlinux.org", or cat a file that has links
3. CTRL-click on the link, it's going to open it in a root-permission web browser.

[skidoo]

links are handled by the operating system, it's not the program that decides how they are opened

I skimmed the code again today & gained some new insight. The cause of the problem, and its solution, seems pretty straightforward.
Any app which invokes an mx-viewer subprocess, e.g. MX-live-usb-maker https://github.com/AdrianTM/mx-live-usb ... w.cpp#L322
should not be concatenating "su" into the string used for the system() call
(or should not trust that "user.toUft8()" returns SUDO_USER, vs result of "whoami")
If, someday, a need arises to open a document residing in path readable only by root, mx-viewer is probably the wrong tool for the task.

In the meantime, across all the MX Tools, every call involving mx-viewer or xdg-open ( not just the call from within on_buttonAbout_clicked() )
could be using sudo -u somenonpriviledgeduser

Code: Select all

void MainWindow::on_buttonAbout_clicked() {
    . . .
        . . .
        QString user = c.getOutput("logname");
        if (system("command -v mx-viewer") == 0) { // use mx-viewer if available
            system("su " + user.toUtf8() + " -c \"mx-viewer file:///usr/share/doc/CUSTOMPROGRAMNAME/license.html 'Custom_Program_Name " + tr("License").toUtf8() + "'\"&");
        } else {
            system("su " + user.toUtf8() + " -c \"xdg-open file:///usr/share/doc/CUSTOMPROGRAMNAME/license.html\"&");
        }
    }
    this->show();
}

[dolphin_oracle]

I'm missing how your sudo command is any different than the current su command, given that the hard part is figuring the user to use when running inside a root application.

It's not obvious to me.

[Adrian]

How is that going to solve what is openned when clicking on links?

Also, user.toUtf8() is just a variable of the stuff that is returned by "logname". "whoami" would return "root" which is not what we need. Try "sudo logname" vs. "sudo whoami" to see the difference...

[skidoo]

> hard part is figuring the user to use

I'm not familiar with the various QEnvironment::methods, so can't suggest which one would reliably return SUDO_USER environment value (and I wouldn't presume that env var will always be populated). In the absence of other solutions, the packaging could include a post-install instruction, ala `adduser mxdocviewer -args` to create a "known-to-exist and non-priviledged" user.

Code: Select all

system("sudo -u mxdocviewer" + . . .

[dolphin_oracle]

> hard part is figuring the user to use

I'm not familiar with the various QEnvironment::methods, so can't suggest which one would reliably return SUDO_USER environment value (and I wouldn't presume that env var will always be populated). In the absence of other solutions, the packaging could include a post-install instruction, ala `adduser mxdocviewer -args` to create a "known-to-exist and non-priviledged" user.

Code: Select all

system("sudo -u mxdocviewer" + . . .

we actually wrap Qt around bash for that, so if you can do it in bash, we can do it in the mx apps.

that last is an interesting idea though...