Veracrypt 1.26.18 doesn't show admin/user password dialog for mounting container file on Linux Mint

[PlayfulThomas]

Expected behavior

After showing dialog to enter file container password for decrypting, Veracrypt should display a dialog to enter admin/user password for mounting decrypted file.

Observed behavior

Veracrypt doesn't show admin/user password dialog at all, but instead shows processing symbol for few seconds, possibly trying to mount decrypted container file, and then displays error message like "Unable to gain administrator privileges". After this, it keeps trying again to mount, but fails again with same error message.

Steps to reproduce

1. Open Veracrypt GUI
2. Select slot and container file, and click Mount
3. Enter password for file container

Environment

This behaviour has been tested on following OS - installer combinations

Linux Mint 21.0 Xfce - veracrypt-1.26.18-Ubuntu-22.04-amd64.deb - Doesn't work
Linux Mint 21.0 - veracrypt-1.26.18-setup.tar.bz2 - Doesn't work
Linux Mint 22.1 Cinnamon - veracrypt-1.26.18-setup.tar.bz2 - Doesn't work
---
Linux Mint 21.0 Xfce - veracrypt-1.26.14-Ubuntu-22.04-amd64.deb - Works (v1.26.14)
Xubuntu 24.04.1 - unknown - Works
Debian 13 - veracrypt-1.26.18-setup.tar.bz2 - Works
OpenSUZE Tumbleweed - veracrypt-1.26.18-setup.tar.bz2 - Works

("Works" meaning Veracrypt is functioning as it should)

VeraCrypt version:
1.26.18

Operating system and version:

System:
  Kernel: 5.15.0-130-generic x86_64 bits: 64 compiler: gcc v: 11.4.0
    Desktop: Xfce 4.16.0 Distro: Linux Mint 21 Vanessa base: Ubuntu 22.04 jammy

System type:
64-bit

[H-andy]

I've seen the same problem in Linux Mint 22.1 Cinnamon 6.4.6.

However, I found a workaround by adding the parameter "--use-dummy-sudo-password" to the command line when launching VeraCrypt 1.26.18 from the GUI or terminal.

In this case, after entering the volume password the user is presented with the "Administrator privileges required" prompt through which the user password may be provided.

This results in the volume being mounted and dismounted correctly.

Is this issue related to the recent change "* Simplify sudo session detection logic" ?

Despite a potential workaround, I have reverted to version 1.26.14 pending more information.

System Environment:

 Operating System: Linux Mint 22.1 (Ubuntu 24.04)

Desktop Environment: Cinnamon 6.4.6
Linux Kernel: 6.8.0-51-generic
VeraCrypt Version: 1.26.18-1~ubuntu24.04-1
Package Installed: veracrypt-1.26.18-Ubuntu-24.04-amd64.deb
Dependencies: dmsetup 2:1.02.185-3ubuntu3.1
libayatana-appindicator 3-1 0.5.93-1build3
libccid 1.5.5-1
libfuse2t64 2.9.9-8.1build1
libgtk-3-0t64 3.24.41-4ubuntu1.2
libpcsclite1 2.0.3-1build1
pcscd 2.0.3-1build1
sudo 1.9.15p5-3ubuntu5

[idrassi]

Thank you for this detailed report.
We tested only on the distributions where we build VeraCrypt (Ubuntu/Debian/CentOS/Fedora/OpenSUSE) and we didn't encounter this issue. So it seems that the new sudo detection logic causing this regression on Linux Mint, which is strange because it is supposed to be based on Ubuntu.

As indicated by @H-andy, using --use-dummy-sudo-password should solve the issue on Mint Linux since it bypasses sudo session detection by sending dummy password.

FYI, the new logic in 1.26.18 is based on -l switch of sudo which will make it exit with a value of 0 only if the user is allowed to run sudo. So it looks like on Linux Mint it always returns 0 which would explain the behavior.

I will install Linux Mint to investigate the reason.

[idrassi]

@PlayfulThomas @H-andy
I have installed Linux Mint 22.1 and I can confirm their sudo has a bug: it always has exit code set to 0 even if there is no active sudo session.
Test is simple: open Terminal, type the following sequence:

sudo -n -l
echo $?

the last echo statement should print 1 since no sudo session is active. But in Linux Mint, it prints 0. More over, sudo -n -l prints long text that is not printed on Ubuntu.

There is clearly something wrong in sudo of Linux Mint because "man sudo" on it contains the following:

   If the -l option was specified without a command, sudo, will exit
   with a value of 0 if the user is allowed to run sudo, and they
   authenticated successfully (as required by the security policy).
   If a command is specified with the -l option, the exit value will
   only be 0 if the command is permitted by the security policy,
   otherwise it will be 1.

So the observed behavior of sudo -l on Linux Mint contradicts its own man documentation!

To me, Linux Mint maintainers have done something to sudo that changed its behavior compared to its base distribution Ubuntu and going against sudo official documentation. This is strange and a little worrying.

In my opinion, this behavior should be reported to Linux Mint maintainers to seek clarifications.

[affe42]

I got the same "no admin/user password dialog"-issue with Debian 12, so this problem is not only affecting Linux Mint.

[idrassi]

@affe42
I have just tested again on Debian 12 and there is no issue.
My install of Debian 12 is vanilla without any changes to the system.

Can you please run the commands shown above in a new Terminal and report the result:
sudo -n -l
echo $?

echo should print 1 like the screenshot below taken on Debian 12:

[idrassi]

@affe42

Below is a recording of a mounting a file container on Debian 12 that works as expected:

Debian12-screen0.webm

I'm really interested in knowing what is different in your case. On my Debian 12 system, sudo version is 1.9.13p3.

[affe42]

Hi @idrassi

It's like that (account / system name masked with XXXX):

XXXX@XXXX:~$ uname -a
Linux XXXX 6.1.0-30-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12) x86_64 GNU/Linux

XXXX@XXXX:~$ sudo -n -l
Matching Defaults entries for XXXX on XXXX:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User XXXX may run the following commands on XXXX:
    (ALL : ALL) ALL
    (root) NOPASSWD: /usr/sbin/nethogs
    (root) NOPASSWD: /usr/sbin/iftop
    (root) NOPASSWD: /usr/sbin/iotop

XXXX@XXXX:~$ echo $?
0

XXXX@XXXX:~$ sudo -V
Sudo version 1.9.13p3
Sudoers policy plugin version 1.9.13p3
Sudoers file grammar version 50
Sudoers I/O plugin version 1.9.13p3
Sudoers audit plugin version 1.9.13p3

And like others reported, reverting to previous version of VeraCrypt fixes the "no prompt"-problem.

[idrassi]

Thank you for sharing the results. This is intriguing because I cannot replicate the behavior on any Debian 12 image, including cloud environments like AWS and Azure. So there must be some non-standard configuration affecting the behavior of the sudo -l switch in your environment.

After digging sudo source code and analyzing the Linux Mint sudo configuration, I identified the root cause: the presence of NOPASSWD rules in /etc/sudoers.d/mintdrivers and /etc/sudoers.d/mintupdate.

These NOPASSWD rules allow specific commands to be executed without requiring a password. When you run sudo -n -l, the existence of these rules is enough for sudo to report privileges and exit with a code of 0, even if there is no active sudo session. Normally, the NOPASSWD rules apply to specific commands but in this case, since no command is specified, sudo defaults to considering the user as authenticated.

@affe42: Could you please check the contents of /etc/sudoers.d/ on your system and confirm whether there are NOPASSWD rules in one of its files?

This explains why I’m unable to reproduce the behavior on my end. By default, there are no NOPASSWD rules in the configuration and I avoid using them in my setups.

Unfortunately, the use of NOPASSWD rules breaks the new VeraCrypt implementation. Given this, I will revert the change as there doesn’t seem to be a viable alternative.

For reference, here is the flow I extracted from the sudo source code. The presence of NOPASSWD rules falls under Case 2:

sudo -l switch
   |
   v
policy_list() (called in main from sudo.c)
   |
   v
policy_plugin.u.policy->list (function pointer)
   |
   v
sudoers_list()
   |
   v
sudoers_check_common()
   |
   v
check_user()
   |
   v
User Authenticated?
   |
   |-- No --> AUTH_SUCCESS in two cases:
   |          |
   |          |-- Case 1: MODE_POLICY_INTERCEPTED is set
   |          |        AND def_intercept_authenticate is NOT configured to authenticate
   |          |        (lines 109-111 of check_user source code)
   |          |
   |          |-- Case 2: Authentication is disabled OR user is exempt (NOPASSWD rules fall here)
   |                   |  (lines 131-138 of check_user source code)
   |                   |
   |                   |-- Authentication is disabled: def_authenticate is false
   |                   |
   |                   |-- User is exempt: user_is_exempt(ctx) returns true
   |
   |-- Yes --> Proceed with authenticated actions
               |
               |-- If user is approved by sudo_auth_approval(ctx) (post-auth check),
               |      timestamp is updated (if required by mode).
               |
               |-- If timestamp update fails, it is logged but not fatal.

[morton-f]

Copy of my comment on the Forum:

Here some additional data to the issue:

Debian 12
no issue
NOPASSDD in sudoers.d - absent

Debian 13
no issue
NOPASSDD in sudoers.d - absent

Linux Mint 21.1
issue
NOPASSDD in sudoers.d - present

#Debian 12:

 $ sudo -n -l
Matching Defaults entries for mf on d12c:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty, timestamp_timeout=1, env_reset, timestamp_timeout=1

User mf may run the following commands on d12c:
    (ALL : ALL) ALL

$ echo $?
0

#Debian 13:

$ sudo -n -l
Matching Defaults entries for mf on debian:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty, timestamp_timeout=1

User mf may run the following commands on debian:
    (ALL : ALL) ALL

$ echo $?
0

#Linux Mint 21.1:

$ sudo -n -l
Matching Defaults entries for mf on T7LM211EN:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty, pwfeedback

User mf may run the following commands on T7LM211EN:
    (ALL : ALL) ALL
    (root) NOPASSWD: /usr/bin/mintdrivers-remove-live-media
    (root) NOPASSWD: /usr/bin/mint-refresh-cache
    (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/synaptic-workaround.py
    (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/dpkg_lock_check.sh

$ echo $?
0

[idrassi]

Thank you @morton-f for the information. This confirms my analysis of NOPASSWD effect.

I just have a doubt about the output of commands you shared for Debian11/Debian12/Mint21.1 because all of them have exit code 0. I suspect that you had an active sudo session because on Debian without NOPASSWD, exit code is 1 when there is no active sudo session.

Anyway, parsing files in /etc/sudoers.d in not possible without root privileges and I couldn't find a way to detect if a NOPASSWD rule is enabled. So, I will revert the change.

[morton-f]

"I just have a doubt about the output of commands you shared for Debian11/Debian12/Mint21.1 because all of them have exit code 0."
I noticed that too, and triple check, there was exit code 0 and no other session. Maybe being inside sudo timeout is enough?
I had exit code 0 in Ubuntu live session under ubuntu user 1000 as well.

[eakaye]

There is clearly something wrong in sudo of Linux Mint because "man sudo" on it contains the following:

   If the -l option was specified without a command, sudo, will exit
   with a value of 0 if the user is allowed to run sudo, and they
   authenticated successfully (as required by the security policy).
   If a command is specified with the -l option, the exit value will
   only be 0 if the command is permitted by the security policy,
   otherwise it will be 1.

So the observed behavior of sudo -l on Linux Mint contradicts its own man documentation!

On my system (LM 22.1, upgraded from 22.0), the relevant section says:

-l, --list
If no command is specified, list the privileges for the invoking user (or the user specified by the -U option) on the current host. A longer list format is used if this option is specified multiple times and the security policy supports a verbose output format.

If a command is specified and is permitted by the security policy for the invoking user (or the, user specified by the -U option) on the current host, the fully-qualified path to the command is displayed along with any args. If -l is specified more than once (and the security policy supports it), the matching rule is displayed in a verbose format along with the command. If a command is specified but not allowed by the policy, sudo will exit with a status value of 1.

Nothing about the return value when run without a specific command. So it looks like not every LM has the same sudo. Running apt install sudo reports that it's already the latest version. If it matters, my system pulls from the Cogent mirror of the repositories rather than the "main" ones, although hopefully there's no discrepancy there.

[morton-f]

. So it looks like not every LM has the same sudo.

Linux Mint is using Ubuntu sudo man pages as well as other related to sudo files. sudo man pages were edited between realeses, your is 24.04 LTS, see https://manpages.ubuntu.com/manpages/noble/man8/sudo.8.html
Anyway I tested the issue on Linux Mint 19, 20, 21 and 22 and 22.1 using the same generic binary and all mentioned had the same issue, caused by LM standard customization.

[morton-f]

Compiled from git and resulting VeraCrypt 1.26.19 was flawless on Linux Mint 21.2.

[idrassi]

Thank you @morton-f for the confirmation.
It turned the simplest solution is the best...I have changed this sudo handling part many times, first using "uptime" command and then using '-l' switch. Sometime I go for complexity without objective reasons...

I will publish new release with this change.

[MikeNavy]

Hi,

I have the problem with Linux Mint 21.3 Mate, based on Ubuntu 22.04, and Veracrypt 1.26.18 (installed from https://launchpad.net/veracrypt/trunk/1.26.18/+download/veracrypt-1.26.18-Ubuntu-22.04-amd64.deb). I use GUI version only.

Note that I don't use Linux Mint sudo, but "sudo1.9.16p2" downloaded from sudo.ws website, https://github.com/sudo-project/sudo/releases/download/SUDO_1_9_16p2/sudo_1.9.16-3_ubu2204_amd64.deb.

Here is the output of my "sudo -n -l" command:
sudo -n -l

Entrées Defaults correspondant pour username sur computername :
secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin,
env_keep+="LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET", env_keep+="XAPPLRESDIR
XFILESEARCHPATH XUSERFILESEARCHPATH", mail_badpass, pwfeedback

Paramètres par défaut de runas ou spécifiques aux commandes pour username :
Defaults!/usr/sbin/visudo env_keep+="SUDO_EDITOR EDITOR VISUAL"

L'utilisateur username peut utiliser les commandes suivantes sur computername :
(ALL : ALL) ALL
(root) NOPASSWD: /usr/bin/mintdrivers-remove-live-media
(root) NOPASSWD: /usr/bin/mint-refresh-cache
(root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/synaptic-workaround.py
(root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/dpkg_lock_check.sh

Here is the corresponding extract of "man sudo":
-l, --list
If no command is specified, list the privileges for the invoking
user (or the user specified by the -U option) on the current
host. A longer list format is used if this option is specified
multiple times and the security policy supports a verbose output
format.
If a command is specified and is permitted by the security policy
for the invoking user (or the, user specified by the -U option)
on the current host, the fully-qualified path to the command is
displayed along with any args. If -l is specified more than once
(and the security policy supports it), the matching rule is dis‐
played in a verbose format along with the command. If a command
is specified but not allowed by the policy, sudo will exit with a
status value of 1.

So, I am not sure the problem comes from "Linux Mint sudo".

Finally, note that sudo should not be used to launch graphics applications, but commands only. Graphics applications needing super-user privileges should be launched with pkexec command. Without an available polkit policy, you can use a pseudo one, replace "sudo" by "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY".

Regards,

MN

PS: @H-andy, thanks for the workaround, it does work.

[idrassi]

Thank you @MikeNavy for the feedback.

As indicate above, the issue is linked to the presence of NOPASSWD rules that affects the behavior of sudo, so it is not specific to Mint: it just happens that Mint uses NOPASSWD rule to allows anyone to run updates without authentication.

VeraCrypt doesn't use sudo for GUI: sudo is used to spawn a CLI only veracrypt process to manage privileges actions. But indeed, using pkexec could be a better alternative to request credential when VeraCrypt GUI is used while sudo remain for VeraCrypt CLI scenarios.

I will look how complex is it to integrate pkexec support while keeping sudo for CLI and as fallback if pkexec is not available.

PS: there is an old issue about removing admin prompt and the idea is to use a daemon that will run in the background and which VeraCrypt client process will call to perform mount/dismount. This will replicate the behavior on Windows and macOS where no admin password is requested. see #496. This is also something that is worth looking at.

[voxelized-voxel]

I'm a Linux Mint user and considered opening an issue for this, glad to see that someone already did! Hope it get fixed soon.

[PlayfulThomas]

So the observed behavior of sudo -l on Linux Mint contradicts its own man documentation!

To me, Linux Mint maintainers have done something to sudo that changed its behavior compared to its base distribution Ubuntu and going against sudo official documentation. This is strange and a little worrying.

In my opinion, this behavior should be reported to Linux Mint maintainers to seek clarifications.

Unfortunately, the use of NOPASSWD rules breaks the new VeraCrypt implementation. Given this, I will revert the change as there doesn’t seem to be a viable alternative.

@idrassi Do you think this contradiction(?) between man document and behavior caused by NOPASSWD usage should still be reported to LM maintainers?

[loneswimmer]

This error is also present on OpenSuse Leap 15.6

[metal450]

Broken on KDE Neon 6.2 too. The only way I could get out of the infinite loop was to force-terminate VeraCrypt.

[idrassi]

Version 1.26.20 that fixes this issue is in the process of being released. Linux packages are already available on Sourceforge at https://sourceforge.net/projects/veracrypt/files/VeraCrypt%201.26.20/Linux/

[idrassi]

version 1.26.20 has been published on Github: https://github.com/veracrypt/VeraCrypt/releases/tag/VeraCrypt_1.26.20
Closing this issue.

[ski007]

is there an easy way to revert to a previous version of veracrypt ? :-) ...my system:
Distributor ID: Linuxmint
Description: Linux Mint 21.3
Release: 21.3
Codename: virginia
.................
Linux kris-server 6.8.0-52-generic #53~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 15 19:18:46 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

ps. I have a script that I run on the LAN to mount drives and so far it has worked fine but now I have a problem and have to do it manually. ..... OK / Github / version: VeraCrypt_1.26.20 / deb working ! :-)

[SomeTroglodyte]

A heart-felt Thank You for the quick fix (and from the release here to availability in the PPA was super fast too).

I originally thought I had upgraded Mint 22.0 to 22.1 without changing the VeraCrypt version, and since Mint changed the dialog style and method with 22.1, I assumed it must have been an issue with that. I actually got VeraCrypt 1.26.18 to mount volumes on the new Mint, showing the new-style dialog - but I couldn't reproduce how I tricked it into doing so, thus I didn't post a report here...

Mint 22.0 dialogs vs Mint 22.1 ones

Mint 22.1 (not from VeraCrypt but from Chromium):

Mint 22.0 or 22.1 with VeraCrypt 1.26.20: