You are not logged in.
Application name and path: /usr/local/bin/arch.sh
Currently, I'm getting asked to enter my password:
$ sudo /usr/local/bin/arch.sh
[sudo] password for user:
/etc/sudoers.d/arch:
user ALL=(ALL:ALL) NOPASSWD: /usr/local/bin/arch.sh
/etc/sudoers.d/wheel:
%wheel ALL=(ALL:ALL) ALL
visudo:
root ALL=(ALL:ALL) ALL
## Read drop-in files from /etc/sudoers.d
@includedir /etc/sudoers.d
sudo check:
$ sudo visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/arch: parsed OK
/etc/sudoers.d/wheel: parsed OK
group check:
$ groups user
wheel user
Last edited by bedtime (2023-11-12 22:51:00)
Offline
user ALL=(ALL:ALL) NOPASSWD: /usr/local/bin/arch.sh
Is your username called 'user'?
Offline
Without password for everything is dangerous, Doas for only some is better
Offline
Without password for everything is dangerous
And that's not what the OP is doing, so this caution isn't relevant.
Doas for only some is better
No, it isn't. It was exactly the same configuration mechanics for specifying that certain commands can be run with no password.
Bedtime, it would seem the only issue is that you missed the % before 'user' in sudoers.
Last edited by Trilby (2023-11-12 13:31:09)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Trilby, "groups user" idicates, that the user is either called user or OP is trying to obfuscate the actual username.
Offline
Oops, yes. I didn't even look at the user name passed to `groups` but just saw 'user' as a group that it printed.
I've always found having a group name matching a user name to be confusing (yes, even for services using 'http' or similar). And posting commands / output while deliberately obfuscating them is a few rungs lower than just "confusing".
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
So let's unconfuse this
sudo -l
Online
Trilby, "groups user" idicates, that the user is either called user or OP is trying to obfuscate the actual username.
The username is 'user'. I've always used this, and it's worked fine for me.
Trilby,
I tried putting a '%' infront us 'user' as such:
%user ALL=(ALL:ALL) NOPASSWD: /usr/local/bin/arch.sh
After reboot I still get:
$ sudo /usr/local/bin/arch.sh
[sudo] password for user:
Seth, I get:
$ sudo -l
User user may run the following commands on Arch-Linux:
(ALL : ALL) NOPASSWD: /usr/local/bin/arch.sh
(ALL : ALL) ALL
Offline
type sudo
Online
type sudo
It gives:
$ type sudo
sudo is /usr/bin/sudo
Offline
Sanity check, what does "/usr/local/bin/arch.sh" actually look like?
Online
Sanity check, what does "/usr/local/bin/arch.sh" actually look like?
This isn't the original file, but replacing it with this and rebooting gives the same result:
#!/bin/bash
htop
Last edited by bedtime (2023-11-12 22:42:28)
Offline
I was hoping for maybe some inner sudo statements that would drop and try to re-raise privileges (far stretch…)
What if you rename in the includes "1-wheel" and "99-arch"?
I've never not sorted the rules from generic to specific and frankly dk whether that's relevant…
Online
I was hoping for maybe some inner sudo statements that would drop and try to re-raise privileges (far stretch…)
What if you rename in the includes "1-wheel" and "99-arch"?
I've never not sorted the rules from generic to specific and frankly dk whether that's relevant…
Lol, I just tried that before even looking here, and it WORKED!
Bizarre, but it's solved now.
Last edited by bedtime (2023-11-12 22:51:31)
Offline
When multiple entries match for a user, they are applied in order. Where there are multi‐
ple matches, the last match is used (which is not necessarily the most specific match).Files are parsed in sorted lexical order. That is, /etc/sudoers.d/01_first will be parsed
before /etc/sudoers.d/10_second. Be aware that because the sorting is lexical, not nu‐
meric, /etc/sudoers.d/1_whoops would be loaded after /etc/sudoers.d/10_second. Using a
consistent number of leading zeroes in the file names can be used to avoid such problems.
After parsing the files in the directory, control returns to the file that contained the
@includedir directive.
It's easy to find when you know what you're looking for
Online
man sudoers wrote:When multiple entries match for a user, they are applied in order. Where there are multi‐
ple matches, the last match is used (which is not necessarily the most specific match).Files are parsed in sorted lexical order. That is, /etc/sudoers.d/01_first will be parsed
before /etc/sudoers.d/10_second. Be aware that because the sorting is lexical, not nu‐
meric, /etc/sudoers.d/1_whoops would be loaded after /etc/sudoers.d/10_second. Using a
consistent number of leading zeroes in the file names can be used to avoid such problems.
After parsing the files in the directory, control returns to the file that contained the
@includedir directive.It's easy to find when you know what you're looking for
I gotta start digging into the man files more.
Offline