I don’t like having to keep re-typing the password every time I enter a devel-su command. I think it’s normal in Linux wirh sudo that once you enter it successfully once, it doesn’t ask anymore.
2 Likes
Possible solution - install sudo, edit sudoers file:
sudo visudo
add line:
Defaults timestamp_timeout=15
where '15 is the new timeout in minutes.
2 Likes
No, this isn’t normal. sudo by default doesn’t ask for the password in a certain amount of time, not for your whole session.
Install sudo and configure it for NOPASSWD for nemo/defaultuser if you don’t want to type your password - this way you are responsible for your own security.
1 Like
@margaritv @gabrielg - I already am using sudo and sometimes su. I was just making the point about devel-su, since it’s SF-specific.
I guess I was wrong about sudo… I never looked into it, but I was just going by my experience on Debian. Maybe devel-su can work the same way as sudo, however it is…
Sure, but unfortunately you want to switch a default for everybody that is inherently less secure. None of the other tools to do similar tasks behave as you wish by default.
I believe that there are bigger fish to catch, given that the way to work around this inconvenience is doing what you did.
1 Like
Wouldn’t this same criticism go for sudo on regular distros then?
People seem to agree that it is secure enough, and if someone wants it differently, the can configure that.
I wouldn’t assume @Levone1 wants no timeout, and that nothing else would do, just because that’s how the post reads (it also refers to regular distros…). Having it work like sudo would probably take care of the situation just fine.
Maybe i’m mistaken, but i seem to recall devel-su not being able to work on individual commands at all many years ago, and only work like su. The semi-sudo functionality seems like an afterthought, and i completely agree that going all the way and having it work like regular sudo only makes sense.
Why does it have to exist at all (and not just be sudo) in the first place btw?
No, the OP talks about “per session”, which isn’t like sudo/doas/runuser work - in fact, the last 2 ask for password always by default.
Perhaps, but I don’t like guessing so I’m answering the question that’s been posed.
Perhaps, however, like I said: there are bigger fish to catch than fixing this, when sudo is also available.
You would have to ask whoever made the decision to include it. It doesn’t offend me and I can always use sudo, so I’m not sure what the deal is here.
I would be in complete agreement if there were no alternatives available, but what do we want from Jolla as a new feature here? "Hey, Jolla! Invest time making devel-su to work exactly like sudo" or “Hey Jolla! Make some effort to replace devel-su with sudo in the bootstrap images”.
Perhaps I’m not understanding the real problem here, as I wouldn’t believe that it is only to avoid installing sudo, which is literally 2 commands (maybe 3 if for some reason you need pkcon refresh).
I think it is pretty obvious from the comment you replied to that it is the basic grace period (s)he is after, no special config.
But please @Levone1, do confirm.
I completely agree it shouldn’t be top prio, but the argument you make can be used for basically any functionality. I think OOTB experience is important, and “you can just install it yourself” isn’t exactly user friendly.
Many feature requests are completely valid as a way to know that a wish exists, and when that part of the system is due a makeover anyway, some of them can be incorporated. After all it has been a long time, maybe sudo can already do what is needed nowadays.
1 Like
Sure, but the title hasn’t changed, and you have to consider other folks who come here to read this forum and don’t pay as much attention to detail as you do.
Personally, I think that the strategy should be to not require to become root in the first place. If you are in this area, then you know what you’re doing and SFOS isn’t forcing you to type the password every single time as you have options.
In fact, OpenBSD ships only with doas in its default install - if you ever try to tell them to change that behaviour -or even better: switch back to sudo, I would very much like to see what they respond 
I’m not sure about this - going through feature requests and weighing them is time consuming. I am being vocal about this (and other similar things) as they just take time to digest, not only from a community perspective but also from Jolla. IMHO, there are better conversations to be had.
I reiterate: I would be backing this if I understood that this inconvenience can’t be fixed with 2 or 3 commands.
1 Like
yes. But anyone who takes the time to read and respond with input is appreciated … I think it’s true that there are bigger fish to catch, but ideally we would catch all of the fish, so it doesn’t hurt to drop a little note in the suggestion box. I guess there is probably a line to try to not cross, as @gabrielg said, so as not to waste anyone’s time who would have to go through it, bit I don’t personally feel that this is over that line. It’s probably not a big job to change it… But I wouldn’t losr too much sleep over it if it didn’t change.
1 Like
Agree. It is annoying as hell.
Who made it behave different from sudo in the first place? What was on their mind?
it came from Meego.
"Harmattan devices include a built-in root account that you can access with the devel-su command line tool that is available when developer mode is active. The default password for the root account is ‘rootme’.
Unlike in many other UNIX systems, the root account in Harmattan does not have unrestricted access to system resources. Instead, root is a standard user account that retains file ownership and has an expanded set of commands and slightly less restricted access to system resources."
2 Likes
I agree, it gets annoying having to type my password every time. Going root is an option, but then I get two command histories, which is inconvenient.
Instead of sudo, which is quite a heavy binary, I prefer doas as it is lightweight, has less code to carry bugs, and gets the same thing done - for me at least. It doesn’t seem to be available in Openrepos either, so currently I’m just using devel-su for now.
1 Like
Haven’t used doas before, but it seems to build and install on my XZ2c pretty easily, but still figuring it out… Somehow the conf file doesn’t seem to be being created properly.
AFAIK the config file doesn’t exist by default (at least on Manjaro package it doesn’t) and has to be created manually.
I was planning on packaging doas and releasing it in Openrepos, but it doesn’t look like I have the time today…
2 Likes
I probably misunderstood you.
Do you mean that each time you write devel-su command, shell prompts for the password, and that annoys you?
Have you tried devel-su without any commands? Shell prompts for the password, and after that you get root previleges until you exit. Or at least I have always exited before I’m cast out.
Is this what you want? Or do you mean that you want root previleges each time you open a new terminal without having to enter the password?
1 Like
I was just comparing it to my experience on Linux with sudo. If you type sudo (something), it will ask you for pasword, but then you will still be regular user, ($ not #). Then if you again type sudo (something), it will just do it without asking for a password, until a certain timeout happens.
I looked into it more and created conf, but always get syntax error.Trying to figure out spacing etc. Seems like it may be system-dependant to some degree. In searching for information, I see many reports of syntax error issues, and a lot of the answers are “try with an arg and see if that works …”, etc., but the docs indicate that the file is very basic in content and in syntax. E.g. “permit nemo as root”
Well, I got past the syntax issue and now running into setuid security issues, which is over my head … I’ll just leave it up to you …
You are aware just using devel-su on its own will drop you into a root shell right.
Just combine that with tmux or screen and use the root shell whenever needed.
No need for complicated sudoer or other schemes.
2 Likes