prompt sudo password

Question

is there a way to prompt for sudo password inside vifm when accessing restricted directories, copy/moving files ecc, without executing vifm as root?

Answer 1

I worked around that with this custom configuration

nnoremap <c-s> :!sudo -E vifm %c<cr>
if system('whoami') == "root"
  hi StatusLine guifg=#fb4934
endif

Comments

Right, there is no builtin support for executing anything as a different user and not sure there is a nice way of doing it.

By the way, you should be able to use $USER in place of system('whoami').

---

thank you for the heads up, I was overcomplicating things for sure
regarding the privileged instance I ended up with

nnoremap <c-s> :!sudo -E unshare --mount vifm %d %D<cr>

because I need to be able to mount a remote system on the same path, with both user and root, at the same time; this to avoid continuous mounting/unmounting when switching instances.
It's kinda tricky and I'm trying to see if I can edge it out; among the remaining quirks is that when I close the elevated vifm instance and get back to the previous user instance that was in background, it do not immediately display some changes I applied in the elevated instance, like file/directory ownership. Is there a way to automatically refresh the background instance as soon as the foreground one is closed?

edit: on another note, the command vifm %d %D doesn't seems to trigger DirEnter, so autocmd DirEnter configuration is ignored when executing the new vifm instance, even if %d and/or %D are referenced paths part of autocmd DirEnter configuration. Is that working as intended or it's an exception? is there a workaround I can use to avoid manually re-enter on those paths once inside the new vifm instance?

---

Is there a way to automatically refresh the background instance as soon as the foreground one is closed?

You can execute :redraw afterwards:

nnoremap <c-s> :execute '!sudo -E unshare --mount vifm %d %D' | redraw<cr>

autocmd DirEnter configuration is ignored when executing the new vifm instance

Does this configuration apply to the new instance or is it specific to the current user? You may want to move common configuration to /etc/vifm/vifmrc, so it's shared across users.

---

I confirm that the configuration is successfully shared from user to root with -E argument. I think I've expressed myself poorly, let me clear this with an example:

I have multiple snippet like this in my vifmrc configuration

autocmd DirEnter /mnt/remote2 !sshfs -o allow_other,default_permissions,reconnect,ciphers=aes128-ctr,compression=no $USER@10.10.10.100:/ /mnt/remote2 %i

thata are working flawlessly, so that when I (user) explore /mnt/remote2 from vifm, or I execute vifm from shell and vifm was previously closed with a pane on /mnt/remote2 (or one of its subdirectory) it correctly automounts the remote filesystem.
This snippet is working in the privileged instance too, but it mounts the remote system (in a separate namespace as intended) only if I manually navigate from /mnt to /mnt/remote2.
If, from the unprivileged (user) vifm instance, with /mnt/remote2 open on a pane, I try to execute the above <c-s> remap, it correctly open the privileged vifm instance on that same path but it does not automount the remote filesystem, as if I were entering it instead.
It seems to me that %d %D doesn't count as DirEnter and therefore the sshfs command is not executed? or am I on the wrong path?

ps: piping to redraw fixed the other quirk, thank you

---

DirEnter events are fired for startup directories. You can confirm that under a regular user. If running :autocmd in a privileged instance lists the sshfs command, then my guess is that it fails. Are you sure $USER expands to user and not root after sudo -E?

---

I can confirm that :autocmd indeed list the sshfs command in the privileged instance. After sudo -E, $USER expands to root (as it should?) because that leads to access (and mount) the remote filesystem as root, in a separate namespace so user can only see its mount in the unprivileged instance, while root can access both.
And the privileged mount is working if, once in the privileged instance, I navigate to /mnt/remote2, but it's not working if I execute <c-s> directly to that path with %d %D launch options.
If that fails as an exeption, is there a simple workaround that I could use?

---

It should work. I can't make it to not work (although I'm using different commands). Something else must be going on. Maybe the command fails for some non-obvious reason or something prevents the autocommand from running. Try adding something like echo running-as-$USER >> /tmp/vifm-autocmd to the autocommand to determine which is it. Also if /tmp/vifm-autocmd doesn't get written from root, could run setlocal sort=mtime in an autocommand and then check :set sort? to see whether it got applied for root.

---

I changed the automount to

autocmd DirEnter /mnt/remote2 !sshfs -o allow_other,default_permissions,reconnect,ciphers=aes128-ctr,compression=no $USER@10.10.10.100:/ /mnt/remote2 && echo running-as-$USER >> /tmp/vifm-autocmd %i

and with user it mounts correctly and /tmp/vifm-autocmd is created and owned by user, but if try again with root it do not execute the echo (so it fails the sshfs) unless, worth of noting, the pane is exactly on /mnt/remote2. So if I execute <c-s> while in a subdirectory of /mnt/remote2 it do not execute the mount, but as soon as I navigate back to /mnt/remote2, or navigate in from /mnt, it correctly mounts it, without leaving the privileged instance.
Do you replicate this?

---

I thought you were always running <c-s> from /mnt/remote2. It's not supposed to work from a subdirectory. You can try using /mnt/remote2/,/mnt/remote2/** instead which should do the mounting from a subdirectory, but that can end up invoking sshfs a lot unless you add a check that it's already mounted.

I'm also not sure whether root sees the mount or you get into an empty /mnt/remote2 when things don't work as expected. Since /mnt/remote2 auto-command doesn't get triggered, seems like you stay in a subdirectory.

---

It's not supposed to work from a subdirectory

so that's what I was not considering, thank you for the heads-up.
Logic wise should be an equivalent to a :goto /mnt/remote2/home/test and expect it to automount right? On a side note, could that be implemented or are there compliance/security implications I'm not aware of, that could prevent this?
Otherwise I need to think if this quirk worths an overengineered if statements nesting (check if current path is present in :autocmd output, check if the path is already mounted ecc) to achieve the same result.

I'm also not sure whether root sees the mount or you get into an empty /mnt/remote2 when things don't work as expected. Since /mnt/remote2 auto-command doesn't get triggered, seems like you stay in a subdirectory.

using <c-s> from inside a /mnt/remote2 subdirectory means that in the host namespace (seen by both user and root) that mount already exist, so root see and navigate the user mount but because of that it does not have elevated privileges on the remote filesystem.
From there the needs to be able to remount the remote filesystem separately for each user.

---

Logic wise should be an equivalent to a :goto /mnt/remote2/home/test and expect it to automount right?

Not sure I get the question. DirEnter event is dispatched after directory has been entered and you can't enter a directory which doesn't exist. /mnt/remote2 pattern just doesn't match any nested paths, so that autocommand is not executed unless you also append ,/mnt/remote2/**.

in the host namespace (seen by both user and root) that mount already exist

This is another thing I didn't expect. If the mount wasn't there, Vifm would backtrack to the deepest directory that exists (/mnt/remote2) and ran the autocommand.

---

This is another thing I didn't expect. If the mount wasn't there, Vifm
would backtrack to the deepest directory that exists (/mnt/remote2)
and ran the autocommand.

exactly, I see that happen when user mounts in a separate namespace too

the ,/mnt/remote2/** solution seems to works flawlessly!
And this check solved the multiple sshfs calls

!if ! findmnt /mnt/remote2 | grep "$USER@"; then [...]; fi %i

thank you for the patience and assistance, have a great year's start <3