Can't mount from command line without root privileges since updating

[Evan Kaye]

Running VeraCrypt 1.26.14 on LinuxMint 22.1, I was able to mount a volume from bash by typing the volume passphrase, then my account password. Ever since updating to 1.26.18, I enter the passphrase, but then I get "Warning: Failed to obtain administrator privileges: Sorry, try again." repeatedly until I Ctrl-C. Running the mount command with sudo works, but I'd prefer not to have to. Was anything changed in .18 that would make this necessary? Thanks in advance.

[Mounir IDRASSI]

A similar issue was reported on GitHub: https://github.com/veracrypt/VeraCrypt/issues/1473

Basically, Linux Mint appears to have a unique behavior for sudo that differs from other Linux distributions. In version 1.26.18, we use a feature of sudo to detect whether a sudo session is already active, and this works on all major distributions except Linux Mint.

This is surprising because Mint is based on Ubuntu, and VeraCrypt 1.26.18 works correctly on Ubuntu.

I will begin investigating this issue.

In the meantime, there is a simple workaround: start VeraCrypt with the switch --use-dummy-sudo-password:

veracrypt --use-dummy-sudo-password

Using this, VeraCrypt 1.26.18 will behave normally on Linux Mint.

I will update you with the results of my investigation.

[Evan Kaye]

Thanks, confirmed that VC works as expected with the workaround you provided.

[Mounir IDRASSI]

I have updated Github issue with my findings: https://github.com/veracrypt/VeraCrypt/issues/1473#issuecomment-2611260731

Basically, Linux Mint maintaines have changed the behavior of sudo compared to its base Ubuntu and now sudo behaves differently from its official documentation.

Here is a copy of what I posted on Github:

---

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.

---

[morton]

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

[Cory Ventress]

Hello everyone, I am new here, but after reading this forum I figured it out. The high level overview from Mounir IDRASSI helped a lot. The hot fix worked but I was looking for something more permanent, so here is the formula.

Change directory in the terminal:

cd /etc/sudoers.d/

You will temporarily need to change permissions on mintdrivers & mintupdate using chmod so you can rewrite the text fields using vi, vim or nano, which ever you prefer.

sudo chmod 777 mintupdate
sudo chmod 777 mintdriver

The files are now globally editable this is temporary.

Edit the fields that says NOPASSWD, change them to read PASSWD and save the files.

Next change back the permission for the files mintdrivers & mintupdate

sudo chmod 440 mintupdate
sudo chmod 440 mintdriver

you may or may not need to reboot, I prefer the password prompt when mounting external drives, updates etc.

Please let me know if this helps you. Good luck.

[Mounir IDRASSI]

@humble-dan Thank you very much for this solution. This matches my own finding about the impact of NOPASSWD on the behavior of sudo. I have analyzed sudo source code and I have found that "sudo -n -l" may exit with code 0 if user is exempt (which happens when NOPASSWD specified): https://github.com/veracrypt/VeraCrypt/issues/1473#issuecomment-2613142485

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.

To solve this, I have changed VeraCrypt implementation to use a simpler and more robust approach: https://sourceforge.net/p/veracrypt/code/ci/d6c1526e318c07879741a484ece79347017bf049/

I will publish a new release that includes this fix.

[Göran Johnson]

I have used Mint for several years but have no idea how it works. I also have a problem with VeraCrypt when upgraded to Mint 22.1.
I have used the the tip, - veracrypt –use-dummy-sudo-password -, given here. Thanks for that. However this is a bit unpractical.
Picking up further information here made me try a permanent solution without using the terminal, which I am not familiar with. I went to:

filesystem/etc/ sudoers.d (open as administrator)
Open mintdrivers and change NOPASSWD to PASSWD in two lines and save.
Open mintupdate and do the same as in mintdrivers.

After this VeraCrypt works as before, with Mint 19.3. I have no idea if this solution will cause new problems in the future, but so far so good.