MX Applications - Password Authenticate Dialog Suggestions & Issue

[advice1010]

MX 23.5 XFCE

Up to you guys if you view any of this as being an issue.
This also may occur in other MX applications as well but for now I will focus on "MX Boot Options" and also "MX Package Installer as examples.

1.) When you launch MXBO it instantly opens password dialog.
You are allowed to close this dialog without entering password and yet MXBO still opens after.
The same behavior happens with MXPI as well (Synaptic does not open if password is not entered).
Then if you change anything and try to apply, the password dialog shows up again.
I was thinking, if no conflicts, why not remove the initial password dialog that shows up when application is launched.
Then only show this password dialog IF any changes are made.
Similar to how Featherpad allows you to open up system files but only requires password if something is changed.

2.) I know this one is kind of rare but just happened to me when doing a test for this post so I thought I would mention.
This is especially important if the above item I just mentioned is added to MX applications, but this one might still be worth updating as well.
If you make a change in MXBO and then you hit "Apply" button, the password dialog appears, if you for any reason change your mind and do not actually want to apply the change, the password dialog kind of acts like an "are you sure you want to do this" kind of dialog.
However if you do not enter your password and you hit the "Cancel" button it appears that you are in stuck loop, you cannot cancel and you do not want to enter password and apply :)
Had to go into task manager and kill it! :)

Hope this helps

[dolphin_oracle]

You should be able to cancel the dialogs.


The initial prompts by mxpi and mx boot options are for particular functions. For boot options it populates some combo box i think. I forget what mxpi a does but yes you can do other things if you don’t provide authentication. Unlike synaptic you don’t need root privileges to run the gui s.

[advice1010]

Thank you for response.
I might not understand

1.) I think that is what I said, you can cancel the dialogs and still use both applications.
Can anyone confirm what was mentioned by Dolphin and myself?
For both MXBO and MXPI, if you enter a password in that first password dialog, is it offering something different then if you escape out of it without a password, then make changes, then close application and new password dialog appears and you then enter your password to approve the changes made?
If not it seems like it might be a good idea to remove the initial password dialog that first shows up when you launch these two applications.
Then would only be needed if changes are actually made.

2.) Also if anyone has anything to say about the second item mentioned

Thank You

[FullScale4Me]

2. Use the GUI software as its creators intended or use the command line in the terminal.

Expecting Linux apps to exhibit the same level of odd-clicking handling as Windows apps do is an express ride on the road to disappointment.

[DukeComposed]

Expecting Linux apps to exhibit the same level of odd-clicking handling as Windows apps do is an express ride on the road to disappointment.

This isn't the first thread OP has created asking some form of "Why doesn't this app work the way I think it should?" I have yet to see any patches presented as possible fixes for the perceived matter.

[dolphin_oracle]

Thank you for response.
I might not understand

1.) I think that is what I said, you can cancel the dialogs and still use both applications.
Can anyone confirm what was mentioned by Dolphin and myself?
For both MXBO and MXPI, if you enter a password in that first password dialog, is it offering something different then if you escape out of it without a password, then make changes, then close application and new password dialog appears and you then enter your password to approve the changes made?
If not it seems like it might be a good idea to remove the initial password dialog that first shows up when you launch these two applications.
Then would only be needed if changes are actually made.

in mx-packageinstaller's case, the prompt you get the very first time you run is for setting up flatpak flathub repo. I don't think you get another one if you set allow it to set up the repo.

mx-boot-options is populating the plymouth splash combo box. that box will be empty if the password is not supplied.

2.) Also if anyone has anything to say about the second item mentioned

Thank You

its not quite a loop, but I agree its a little rough. canceling out of the password prompt does work, but its going to ask a few more times before it actually can close. there are several things that happen that require root privileges. if you supply the password for the first one, then it won't ask again. but if you don't, then it will ask again for each subsequent task. a "Downloading...." window might pop up, but hitting the close button on the window behind it (with some dpkg message) will still cancel it out. That could probably be a better, but not sure how at the moment.

[advice1010]

Ahh, I seem to upset a lot trees here in MX Linux land.
Tons I would like to say to you two but then my thread will be closed/locked, so I will keep as short as possible.

@FullScale4Me
I do not understand anything you have said.

@DukeComposed
You came here just to make this response?
If my threads upset you, why do you keep on reading them?
You quoted response of user FullScale4Me about "odd-clicking handling as Windows apps" as defense against my post?

My post is about observations of how the password dialog box is appearing on my machine in different MX tools.

@dolphin_oracle
I apologize, as always Dolphin, you have been kind and helpful but I do not think this is worth continuing, going to stop here before this thread gets locked.
Just to you or any other developers interested, these were just observations I noticed that occur when you use Auto Login.
The purpose of this thread was just to share some things that I just thought could be made smoother for users.
It is okay if there is no interest in the these observations.
As always, thank you again for your responses.

[Adrian]

Might be able to fix the MXPI and MX-Boot-Options prompts, can't say we can eliminate all root prompts, but some of them can be fixed or pushed at more convenient or more obvious stages.

[b3ta]

In case it's no longer 10 presses of "Cancel" in a row

Code: Select all

System:    Kernel: 6.0.0-10.1-liquorix-amd64 [6.0-6~mx21+1] x86_64 bits: 64 compiler: gcc v: 10.2.1 
           parameters: audit=0 intel_pstate=disable hpet=disable rcupdate.rcu_expedited=1 
           BOOT_IMAGE=/vmlinuz-6.0.0-10.1-liquorix-amd64 root=UUID=<filter> ro consoleblank=300 
           threadirqs init=/lib/systemd/systemd 
           Desktop: Xfce 4.18.1 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm 4.18.0 vt: 7 
           dm: LightDM 1.26.0 Distro: Debian GNU/Linux 11 (bullseye) 
           base: Debian GNU/Linux 11 (bullseye) 
Machine:   Type: Laptop System: Dell product: Latitude E6530 v: 01 serial: <filter> Chassis: 
           type: 9 serial: <filter> 
           Mobo: Dell model: 0JC5MT v: A01 serial: <filter> BIOS: Dell v: A22 date: 11/30/2018 
Battery:   ID-1: BAT0 charge: 29.5 Wh (100.0%) condition: 29.5/73.3 Wh (40.3%) volts: 9.5 
           min: 11.1 model: SMP DELL N4FJ513 type: Li-ion serial: <filter> status: Full 
CPU:       Info: Dual Core model: Intel Core i7-3520M bits: 64 type: MT MCP arch: Ivy Bridge 
           family: 6 model-id: 3A (58) stepping: 9 microcode: 21 cache: L2: 4 MiB 
           flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 23123 
           Speed: 2890 MHz min/max: N/A Core speeds (MHz): 1: 2890 2: 2890 3: 2890 4: 2890 
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: mmio_stale_data status: Unknown: No mitigations 
           Type: retbleed status: Not affected 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: 
           conditional, RSB filling, PBRSB-eIBRS: Not affected 
           Type: srbds status: Vulnerable: No microcode 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: Intel 3rd Gen Core processor Graphics vendor: Dell driver: i915 v: kernel 
           bus-ID: 00:02.0 chip-ID: 8086:0166 class-ID: 0300 
           Device-2: Microdia Integrated Webcam type: USB driver: uvcvideo bus-ID: 1-1.5:4 
           chip-ID: 0c45:648b class-ID: 0e02 
           Display: x11 server: X.Org 1.20.14 compositor: xfwm4 v: 4.18.0 driver: 
           loaded: modesetting unloaded: fbdev,vesa display-ID: :0.0 screens: 1 
           Screen-1: 0 s-res: 3520x1200 s-dpi: 96 s-size: 931x317mm (36.7x12.5") 
           s-diag: 983mm (38.7") 
           Monitor-1: LVDS-1 res: 1920x1080 hz: 60 dpi: 142 size: 344x194mm (13.5x7.6") 
           diag: 395mm (15.5") 
           Monitor-2: VGA-1 res: 1600x1200 hz: 60 dpi: 111 size: 367x275mm (14.4x10.8") 
           diag: 459mm (18.1") 
           OpenGL: renderer: Mesa Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa 22.0.5 
           compat-v: 3.1 direct render: Yes 
Audio:     Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Dell 
           driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:1e20 class-ID: 0403 
           Sound Server-1: ALSA v: k6.0.0-10.1-liquorix-amd64 running: yes 
           Sound Server-2: JACK v: 1.9.21 running: no 
           Sound Server-3: PulseAudio v: 14.2 running: yes 
           Sound Server-4: PipeWire v: 0.3.19 running: no 
Network:   Device-1: Intel 82579LM Gigabit Network vendor: Dell driver: e1000e v: kernel 
           port: f080 bus-ID: 00:19.0 chip-ID: 8086:1502 class-ID: 0200 
           IF: eno1 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           Device-2: Intel Centrino Ultimate-N 6300 driver: iwlwifi v: kernel modules: wl 
           port: f040 bus-ID: 02:00.0 chip-ID: 8086:422b class-ID: 0280 
           IF: wlp2s0 state: down mac: <filter> 
           IF-ID-1: pi state: unknown speed: N/A duplex: N/A mac: N/A 
Drives:    Local Storage: total: 447.13 GiB used: 357.41 GiB (79.9%) 
           SMART Message: Unable to run smartctl. Root privileges required. 
           ID-1: /dev/sda maj-min: 8:0 vendor: Patriot model: Burst Elite 480GB size: 447.13 GiB 
           block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> 
           rev: 3A0 scheme: MBR 
Partition: ID-1: / raw-size: 438.11 GiB size: 430.16 GiB (98.19%) used: 357.27 GiB (83.1%) 
           fs: ext4 dev: /dev/dm-0 maj-min: 253:0 mapped: root.fsm 
           ID-2: /boot raw-size: 1024 MiB size: 973.4 MiB (95.06%) used: 145 MiB (14.9%) fs: ext4 
           dev: /dev/sda1 maj-min: 8:1 
Swap:      Kernel: swappiness: 10 (default 60) cache-pressure: 100 (default) 
           ID-1: swap-1 type: partition size: 7.98 GiB used: 0 KiB (0.0%) priority: -2 
           dev: /dev/dm-1 maj-min: 253:1 mapped: swap 
Sensors:   System Temperatures: cpu: 59.0 C mobo: 39.0 C sodimm: SODIMM C 
           Fan Speeds (RPM): cpu: 0 
Repos:     Packages: 3489 note: see --pkg apt: 3437 lib: 1866 flatpak: 52 
           No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian bullseye-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian bullseye main contrib non-free
           2: deb http://security.debian.org/debian-security bullseye-security main contrib non-free
           3: deb http://deb.debian.org/debian bullseye-backports main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/kopia.list 
           1: deb [signed-by=/etc/apt/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://it.mxrepo.com/mx/repo/ bullseye main non-free
           2: deb http://it.mxrepo.com/mx/repo/ bullseye ahs
           Active apt repos in: /etc/apt/sources.list.d/signal-xenial-added-by-mxpi.list 
           1: deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main
           Active apt repos in: /etc/apt/sources.list.d/virtualbox.list 
           1: deb [arch=amd64 signed-by=/usr/share/keyrings/oracle-virtualbox-2016.gpg] https://download.virtualbox.org/virtualbox/debian bullseye contrib
           Active apt repos in: /etc/apt/sources.list.d/webmin.list 
           1: deb [signed-by=/usr/share/keyrings/debian-webmin-developers.gpg] https://download.webmin.com/download/newkey/repository stable contrib
           Active apt repos in: /etc/apt/sources.list.d/protonvpn-stable.sources 
           1: deb https://repo.protonvpn.com/debian stable main
Info:      Processes: 277 Uptime: 2h 43m wakeups: 2 Memory: 7.68 GiB used: 2.42 GiB (31.6%) 
           Init: systemd v: 247 runlevel: 5 default: 5 tool: systemctl Compilers: gcc: 10.2.1 
           alt: 10 Client: shell wrapper v: 5.1.4-release inxi: 3.3.06 
Boot Mode: BIOS (legacy, CSM, MBR)

Might be able to fix the MXPI and MX-Boot-Options prompts, can't say we can eliminate all root prompts, but some of them can be fixed or pushed at more convenient or more obvious stages.

TL;DR:

Maybe this suggestion can help as far as MX Boot Options is concerned: if the user clicks "Cancel" at the very first "Authenticate" pop-up (presented by /usr/bin/pkexec /usr/lib/mx-boot-options/helper cat /boot/grub/grub.cfg), then quit MXBO. If not, you open yourself up to more complex logic in dealing with user input later, as explained in the final paragraph of this post.

Long version, with story

Here's why I say that [story with humour follows, but the point is important].

If you accept that MXBO is a tool you should only really be able to run as root, then it's important to deal with the situation of someone accidentally clicking on it. Regardless, a cancel operation really should.

I expect that the two options presented as buttons ("Cancel" and "Authenticate") mean what they say. Thus if I want to continue, I should click on "Authenticate" and do all the root-y stuff, but if not, then clicking on "Cancel" should bail me out of running MXBO any further.

That's not what happens when you click "Cancel". Instead, the "MX Boot options" window opens, so the casual interloper may be wondering if the authentication was necessary. At this point, if you click on "Close", then it closes, but if you changed something, click on "Apply" (maybe even accidentally), and then decide rather to cancel… well, that's when the pain starts, especially if you believe the final pop-up.

Here is what happened when I tested that workflow, as a story. [Feel free to skip the story, but there is an important point at the end.]

<story>

1. In the "MX Tools" window, you accidentally click on "Boot Options" (it's above "User Manager"…).
2. Since you don't actually want to run MX Boot Options, you click on "Cancel".
3. "MX Boot Options" window opens. Oh well, maybe noodle about a bit to see what the options are. Who knows? Maybe the latest upgrade added something new.
4. Oh, look! Something you do want to change (maybe the menu timeout), so you change it.
5. Just as you click "Apply", you notice that "Boot to" is blank, but you've already clicked "Apply".
6. Panic: Which kernel is going to be booted to, or are you now going to be faced with a GRUB rescue prompt at the next boot? Last time still hurts to think about.
7. Phew!: Another "Authenticate" pop-up, with a "Cancel" option.
8. Press "Cancel"
9. It pops up again, so you press "Cancel" again
10. It pops up again, so you press "Cancel" again
11. It pops up again, so you press "Cancel" again
12. It pops up again, so you press "Cancel" again
13. It pops up again, so you press "Cancel" again
14. It pops up again, so you press "Cancel" again
15. It pops up again, so you press "Cancel" again
16. It pops up again, so you press "Cancel" again
17. It pops up again, so you press "Cancel" again
18. Finally, after ten clicks of "Cancel", another pop-up, but it has what looks like a disc icon, its title is "Operation Complete", and it says "Your changes have been successfully applied."

A deeper level of panic ensues, and because the only button says "OK", you struggle with the temptation to make inferences to the GUI design principles of another OS, which expects you to click on "OK" even when things most definitely aren't.

Save everything, make a backup, and reboot.

Relief when you realise that that last pop-up was lying.

Grateful you have a new backup, you wonder whether you should post on the MX Forum about your trial.

</story>

Running MXBO without root rights makes the logic way more complicated when the user is allowed to make changes and then to click on Apply, with the option of authenticating. As shown in the story, not authenticating at the beginning means that not all of the fields can be filled in, which forces one to check that each field is valid. Then there is the question of why that final pop-up lied.

[Adrian]

I was being lazy, the idea is "you want to use the app, you are presented with a log in prompt, you need to log in" I didn't consider very seriously the case of "I don't want to/can't sign in" you do have a point that people might launch the program by mistake or cancel the prompt by mistake, I will see what I could do if I could differentiate the pkexec error code from the command error code (which both can return 127 in case the command is not found or the password prompt expires), it's also annoying that I have to do that for each and every command that is elevated.