ioBroker
Prevent iob + iobroker being executed as root
Can you provide more infos please about what this change means? WIll it be completely forbidden or just warned?
When 'iobroker' is called with uid=0 (root) the command will aliased with a warning. 'iobroker' can always be called by the system user 'iobroker'. See:
root@chet:~# iobroker status
iobroker can not be executed as root! status
root@chet:~# sudo -u iobroker iobroker status
iobroker is running on this host.
Objects type: jsonl
States type: jsonl
root@chet:~#
Those who know can always override the alias with the backslash:
root@chet:~# \iobroker status
iobroker is running on this host.
Objects type: jsonl
States type: jsonl
root@chet:~#
or use 'command':
root@chet:~# command iobroker status
iobroker is running on this host.
Objects type: jsonl
States type: jsonl
root@chet:~#
No big issue for those who know their system, but those who know won't run iobroker in root context anyway...
Ok ... could we maybe start with an output like
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
iobroker commands should not be executed as root
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
But still doing it?
(And on the other side it is really that way that lxc and docker by default starts as root always ... :-(
LXC/Proxmox can definitely be setup with standard users. And the docker Installation is different anyway. They patch sudo and so on out, afaics.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
iobroker commands should not be executed as root!
Use a standard user to do so or call iobroker with command:
command iobroker OPTION
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
A text like this would be a good first step I think ... it will in any way trigger a lot of discussions/questions
Maybe to be introduced with js-controller 5.0?
Linux is and always was a multiuser system and not a 'We lower our security architecture to the dumbest level' system.
This is a oure installer things and we can introduce anytime ... but please lets start "educational" ... if we block more later we can decide after the first round of "shit storm" ;-)
I basically agree regarding security topic, but we still need to see that also the (partially very unexperienced users!) can use it without too many hurdles
The hint to use the system the way it is designed and pointing to 'command iobroker <COMMAND>' is no big hurdle but makes root usage more annoying than being logged in as a user. And maybe this hint also raises awereness that you are acting under the wrong user. Same as 'sudo' should make the user aware that the next command will be executed as root.
So we are not blocking executing iobroker as root but 'educating' to use a standard user instead.
Talking about very unexperienced users: Especially very unexperienced userst should NEVER jump around as root. I'm tired of fixing systems that have b0rked rights and come up with the strangest error messages. As I always say: Only experienced users should act as root. And these users won't do it, they are experienced enough to know the dangers.
Push... At the moment there are again way too much 'root suicide commiters' to be found in the forum. Please please make it more annoying to use iobroker as 'root' and force the usage of standard users. PLEASE!!!
@Grothesk242 my problem here is that 90% of the docker containsers or lxc's are "root inside" (even if not priviliges) and so it is kind of a strandard there... @buanet I hope i do not tell bullshit here So I have no idea hiow this interferes there?! Ok. our docker container is irrelevant because processes are different, buuutt ....
Docker is irrelevant, the docker installation is heavily patched anyway.
And for LXCs it's good practice to not use a root shell. LXC Standard setup only provides a very basic frame and needs to be configured with a default user. This is already part of the Installation Instructions for iobroker on Proxmox.
And then what's the point in restricting user 'iobroker' with sudoers, ACLs and so on and then allowing the processes be executed as root. Makes no sense and breaks the idea of restricting the users rights.
Other projects do the same, try running VLC as root...
Ingo Fischer @.***> schrieb am Mo., 24. Juli 2023, 13:14:
@Grothesk242 https://github.com/Grothesk242 my problem here is that 90% of the docker containsers or lxc's are "root inside" (even if not priviliges) and so it is kind of a strandard there... @buanet https://github.com/buanet I hope i do not tell bullshit here So I have no idea hiow this interferes there?! Ok. our docker container is irrelevant because processes are different, buuutt ....
— Reply to this email directly, view it on GitHub https://github.com/ioBroker/ioBroker/pull/417#issuecomment-1647711941, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANVE56KI62YWV2UWSNJ4FODXRZKKXANCNFSM6AAAAAATNH2HXM . You are receiving this because you were mentioned.Message ID: @.***>
@Apollon77, I see no problems with the official Docker image, as controller.js is directly called by the user iobroker.
I can't judge whether it makes sense to forbid execution as root in general. I've never heard of broken iobroker docker setups due to executing iobroker something as root inside a container. Perhaps this is because I've implemented a permission check, so the container automatically corrects permissions at every start, even if adapters were installed as root or something else. 😄
Docker is irrelevant, the docker installation is heavily patched anyway.
🤣 Just three things are patched:
- Running as simple process, not as service
- Replacing
sudowithgosu(Docker best practices) - Ensuring the user
iobrokerowns/opt/iobrokerand everything below it.
I hope that helps. Maybe we should discuss this at the developer's meeting to put all pros and cons together.
Regards, André
I think if we add user guidance and documentation about then we can thing about it. I mean:
- I think we have documented how a system need to be setup manually with adding user and such
- How should a User with an existing root system migrate? Such a documentation is missing and could be added then together with the error message
- I would love if we can allow root usage with e.g. a "--allow-root" parameter for a grace period of some months for users to run into it and have a chance to fix it.