You are not logged in.
I've been using YAD with ASKPASS for about 5 years (maybe more), but I've never heard of rrqsu, It seems this method requires less configuration then the way I do it. Thanks for pointing it out.
I did work on a graphical interface for SUDO_ASKPASS in the past, but I stopped working on it time ago.
Just use YAD.
. . . this post is GPLv3. So feel free to use it however you want but please send you changes back to me.
Do you have a git repository for this GPL post where I can submit an issues, or a pull-request?
This looks great. Thanks for posting it.
2. Not related to this sub-forum, but how do I rip my music CD's to my Music folder?
(I read something about "flac" but it apparently isn't loaded on my PC, apt-get didn't get it either)
K3b will do: https://apps.kde.org/k3b/
Just wanted to make it clear to @Tweedlewise that K3b is much more that a cd ripper. It's great software, and you may want the extra features. For example the ability to write CD/DVD disc.
It maybe overkill for simply ripping CDs. If that is the case then something like RipperX or Asunder is a better choice.
A RAID member disk walks into a bar. Bartender asks what’s wrong?
“Parity error.”
“Yeah, you look a bit off.”
I think it also works with udevil instead of pmount
It should since udevil and spacefm are made by the same developer. He made udevil so spacefm wouldn't have to use systemd or other such things..
spacefm & udevil can be used without systemd, consolekit, policykit, dbus, udisks, gvfs & fuse
@chris2be8
I agree. Lots of things aren't a problem for people who understand their system. The issue is non-technical users. Sadly it is those same user who will not made the effort to configure their system properly. Of course I'm sure those users are using sudo, so it's not an issue.
Considering my concern of a fake executable in $HOME, my doas.conf will use the setenv option to override the path order to be more aligned with the expected Linux order (opposed to the original BSD order). Also, I have exclude the paths in $HOME. If I were to add them it would be at the end to be searched last.
permit setenv {PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin} user as root
OK so let's just not make any effort and just let it all be completely proprietary and controlled by the big corps and the government. I really only see the 2 options: FOSS or private controlled. As I said you can't stop it. Or is this just about complaining? Gloom and despair the worlds gonna end.
My point is not that it's a good situation. Just that we should at the very least go down fighting.
. . . and maybe I should of said "help level" which was what I meant.
I'll not follow up on the 3d gun analogy I do have a rebuttal, but don't want to make this thread about guns, or gun control.
My point is not that the danger doesn't exist. We can't stop it, but ensuring that the technology is free and open to everyone will level the playing field.
You can't stop advancement. It's a race, but the more that it is developed in the open with an FOSS license the better. If it's not for everyone it will be abused.
The Honest Government Ad | AI would be a lot funnier if it wasn't for the profanity. Not that I'm sensitive to it, I just think it makes it less funny. I wish comedians would learn that profanity isn't funny . . . OK, sometimes it is funny, because you don't expect it or it's relatable, or on a rare chance creative. Most of the time It just seems to be the results of the lack of creativity.
Update, commands specified using nopass are limited to the restricted PATH. So that's good.
But it still seems that you could still do damage with a fake executable, even if a password is required. Just put it in the local path (in $HOME) like I did with the whoami example above and the user will be tricked to give the password.
of course a better example would be apt because why would you you'd be less likely to use root for whoami.
I'm reporting the issue right now.
I had already thought of that when I made my last post, so I tested it.
I created a fake whoami file in my local path ~/.local/bin/ that simply echos HAHA! The results:
regular user - runs the fake whoami
with sudo - runs the real whoami
with doas - runs the fake whoami
Yep security issue. So you might want to use full path when adding nopass commands.
update : Does not affect nopass commands. See post below.
WOW! You're gonna test all possible configurations. LOL
OK I got it all figured out. It's so simple I can't believe it cause this much trouble. It can be summed up by saying the configuration is very specific. nopass is only allowed if it's exactly as it is in the file. So to sum this all up.
1. If you configure it with args then you have to use the args or it won't work
2. If you configure it with the full path you must use the full path - many graphical apps will need this. For example JWMKit.
3. The reverse is true if you configure as the command line only the command will not work if you do the full path.
So the args do work for me, but I tested without the args assuming it world work with or without them.
When I tested in the terminal it did not work because I did not use the full path as configured in my file.
This is why it worked with the scripts, and graphical apps, as they did use the full path.
So I will configure with multiple combinations.
full path with args
full path without args.
no path with args
no path without args
permit nopass user as root cmd poweroff args -f
permit nopass user as root cmd poweroff
permit nopass user as root cmd /sbin/poweroff args -f
permit nopass user as root cmd /sbin/poweroff
Does any one feel dumb now
To be fair I would expect it to know that poweroff is the same as /sbin/poweroff since /sbin/ is in the exec path. Also I would expect the args to be optional. Maybe requiring it to be exact adds extra security. I mean you could easily manipulate the exec path to hack the system. right?
In a way we were all correct, it's just the configuration wasn't specific enough for zappers setup where he wanted to use both the commandline (no path with args) and jwmkit (path, and no args)
. . . cricket sounds . . .
The party died without golinux here
Oh, One more important thing. This is my experience so I'm not saying this is how it is suppose to behave, just how it does for me. The no pass commands work without a password when NOT started for the command line but if it do them from a terminal it still ask for the password. which is fine for my use case.
So it works with graphical apps, or a menu item, or .desktop file, etc. Just not directly in the terminal.
The system I tested on I only installed the standard system tools or utilities whatever it's called. You know the tasksel menu on the devuan/debian installer. No DE or anything else. It was the only thing selected.
of course then I manually installed the xserver, jwm, and more.
@bilhook
they are not lamentable words, I did actually do it for real
I don't think anyone doubts you. It's just that it didn't work for them. The colon worked for me when it should not have because of my system configuration. Things are like that sometimes.
Thanks yeti!
You are correct, use a colon for groups, and no colon for usernames.
Why did it work for me? you're not gonna believe it. I belong to a group with the same name as as my username. What are the odds. lol.
As I said I usually use groups instead of a username, and since my test with usernames worked with the colons I assumed that was the correct way.
Still my other 2 points are valid. use the full path and the args did not work form me. . . and yes I did test the args after removing the colon.
This works for me.
1 use the full path for the commands2 add a colon before the username 2 the args -f seems to fails, and I don't fully understand the syntax here so I left it out. ** Note below
3
* Code edited for accuracy
permit nopass user as root cmd /sbin/poweroff
On another note, I never configure doas for a specific user, instead I use a group, for example the wheel, or sudo group.
** With a quick look at the documentation, I can see the args syntax works how I thought it did. So I don't know why it causes it to fail for me.
The original number 2 above was marked out due to inaccuracy. Thanks to yeti for his post below. Even though it worked for me it was not correct.
Great news!
I've configured many laptops just as you have, and it works well. The only difference is I just reboot instead of reloading the services.
It may also be helpful to change the behavior of the power key so it does not trigger sleep
I do this by adding the following to logind.conf
HandlePowerKey=poweroff
PowerKeyIgnoreInhibited=yes