[SOLVED] Veracrypt requiring superuser password

armoredkitten · 2019-11-20 11:59:11

I am using Veracrypt to mount an encrypted folder, but I am trying to allow it to do so without requiring sudo. I followed this step in the wiki to set this up, and it was working for a while. But sometime in the past couple of weeks (I'm not sure when, as I don't mount it very frequently), this approach stopped working.

Here's what I have in /etc/sudoers:

%wheel ALL = (root) NOPASSWD:/usr/bin/veracrypt

(And yes, I do use the "wheel" group and not "sudo". And yes, my user is a member of the "wheel" group.)

It now asks for the superuser password when mounting and unmounting the volume, which is what I would like to avoid. Any thoughts?

Last edited by armoredkitten (2019-11-25 00:42:11)

Slithery · 2019-11-20 12:00:18

Post your entire sudoers file.

armoredkitten · 2019-11-20 12:34:02

Sure, here is /etc/sudoers:

## sudoers file.
##
## This file MUST be edited with the 'visudo' command as root.
## Failure to use 'visudo' may result in syntax or file permission errors
## that prevent sudo from running.
##
## See the sudoers man page for the details on how to write a sudoers file.
##

##
## Host alias specification
##
## Groups of machines. These may include host names (optionally with wildcards),
## IP addresses, network numbers or netgroups.
# Host_Alias	WEBSERVERS = www1, www2, www3

##
## User alias specification
##
## Groups of users.  These may consist of user names, uids, Unix groups,
## or netgroups.
# User_Alias	ADMINS = millert, dowdy, mikef

##
## Cmnd alias specification
##
## Groups of commands.  Often used to group related commands together.
# Cmnd_Alias	PROCESSES = /usr/bin/nice, /bin/kill, /usr/bin/renice, \
# 			    /usr/bin/pkill, /usr/bin/top
# Cmnd_Alias	REBOOT = /sbin/halt, /sbin/reboot, /sbin/poweroff

##
## Defaults specification
##
## You may wish to keep some of the following environment variables
## when running commands via sudo.
##
## Locale settings
# Defaults env_keep += "LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET"
##
## Run X applications through sudo; HOME is used to find the
## .Xauthority file.  Note that other programs use HOME to find   
## configuration files and this may lead to privilege escalation!
# Defaults env_keep += "HOME"
##
## X11 resource path settings
# Defaults env_keep += "XAPPLRESDIR XFILESEARCHPATH XUSERFILESEARCHPATH"
##
## Desktop path settings
# Defaults env_keep += "QTDIR KDEDIR"
##
## Allow sudo-run commands to inherit the callers' ConsoleKit session
# Defaults env_keep += "XDG_SESSION_COOKIE"
##
## Uncomment to enable special input methods.  Care should be taken as
## this may allow users to subvert the command being run via sudo.
# Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE QT_IM_SWITCHER"
##
## Uncomment to use a hard-coded PATH instead of the user's to find commands
# Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
##
## Uncomment to send mail if the user does not enter the correct password.
# Defaults mail_badpass
##
## Uncomment to enable logging of a command's output, except for
## sudoreplay and reboot.  Use sudoreplay to play back logged sessions.
# Defaults log_output
# Defaults!/usr/bin/sudoreplay !log_output
# Defaults!/usr/local/bin/sudoreplay !log_output
# Defaults!REBOOT !log_output

Defaults editor=/usr/bin/nano

##
## Runas alias specification
##

##
## User privilege specification
##
root ALL=(ALL) ALL

## Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL) ALL

## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL

## Uncomment to allow members of group sudo to execute any command
# %sudo	ALL=(ALL) ALL

## Uncomment to allow any user to run sudo if they know the password
## of the user they are running the command as (root by default).
# Defaults targetpw  # Ask for the password of the target user
# ALL ALL=(ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'

## Read drop-in files from /etc/sudoers.d
## (the '#' here does not indicate a comment)
#includedir /etc/sudoers.d


# let users in wheel group mount Veracrypt volumes without sudo password
%wheel ALL = (root) NOPASSWD:/usr/bin/veracrypt

NeedCoffee2 · 2019-11-24 13:56:08

I experienced this same problem. Worked around it by uninstalling the veracrypt arch package (1.24.hotfix1-1). Then I downloaded and installed the version 1.23 using the veracrypt-1.23-setup.tar.bz2 file, extracted and ran the appropriate setup script file that it includes. Got veracrypt-1.23-setup.tar.bz2 from https://www.fosshub.com/VeraCrypt.html and clicked on VeraCrypt Linux.

Veracrypt 1.24 and 1.24.hotfix1-1 have an upstream change that is requiring root permissions now. It might be an unintended regression. But, I can't tell from what I have read. Helpful links:

https://bugs.archlinux.org/task/64431
https://sourceforge.net/p/veracrypt/dis … 04d12bba8/

armoredkitten · 2019-11-25 00:40:55

Hmm, okay, yes it's not clear at this point if this is intended behaviour or not. I don't know that I really care enough about it to downgrade it; I just wanted to know if I had somehow set it up incorrectly. Hopefully this gets fixed. But thank you for the response!

Lone_Wolf · 2019-11-25 15:28:36

I am not 100% certain, but I do think sudo stops checking sudoers file when it has found a match .

If that's correct, the first line with %wheel will be used and sudo will never reach the second occurence with %wheel .

try putting

%wheel ALL = (root) NOPASSWD:/usr/bin/veracrypt

above
%wheel ALL=(ALL) ALL

Last edited by Lone_Wolf (2019-11-25 15:29:00)

armoredkitten · 2019-11-27 12:36:09

Lone_Wolf: Changing that seems to make no difference, even after I logged out and back in again. (I don't know offhand when the sudoers file gets sourced.) Thanks for the suggestion, though!

Xavion · 2020-03-02 21:37:37

This is an internal problem with VeraCrypt. I have just made them aware of it in this forum thread. It has already been fixed on some of the other distributions.

Netboy3 · 2020-05-22 13:35:31

Xavion wrote:

This is an internal problem with VeraCrypt. I have just made them aware of it in this forum thread. It has already been fixed on some of the other distributions.

I know this is a relatively old thread, but for posterity's sake I wanted to post the solution. This is not a problem but a side effect from an update to the way VeraCrypt checks if it runs with elevated permissions. The update was introduced early November 19 and showed up since the 2nd update of 1.24 (1.24-Hotfix2). The developers realized that it breaks some of the sudo functionality and added a command line option to force the old sudo behavior (option was added on the same update). Here's what the help info states regarding this option:

--use-dummy-sudo-password Use dummy password in sudo to detect if it is already authenticated

Once you use this option, the sudoers trick will work again without root password prompting.

Xavion · 2020-05-23 00:56:56

@Netboy3:
Thanks for letting us know about that workaround -- much appreciated.

Arch Linux

#1 2019-11-20 11:59:11

[SOLVED] Veracrypt requiring superuser password

#2 2019-11-20 12:00:18

Re: [SOLVED] Veracrypt requiring superuser password

#3 2019-11-20 12:34:02

Re: [SOLVED] Veracrypt requiring superuser password

#4 2019-11-24 13:56:08

Re: [SOLVED] Veracrypt requiring superuser password

#5 2019-11-25 00:40:55

Re: [SOLVED] Veracrypt requiring superuser password

#6 2019-11-25 15:28:36

Re: [SOLVED] Veracrypt requiring superuser password

#7 2019-11-27 12:36:09

Re: [SOLVED] Veracrypt requiring superuser password

#8 2020-03-02 21:37:37

Re: [SOLVED] Veracrypt requiring superuser password

#9 2020-05-22 13:35:31

Re: [SOLVED] Veracrypt requiring superuser password

#10 2020-05-23 00:56:56

Re: [SOLVED] Veracrypt requiring superuser password

Board footer