# Forbid some users to poweroff and reboot the system.



## AlexRyshkov (Apr 3, 2018)

How can I forbid the user in FreeBSD to execute the poweroff or reboot?


----------



## SirDice (Apr 3, 2018)

Only root is able to do that. So, don't give them root access?


----------



## AlexRyshkov (Apr 3, 2018)

SirDice said:


> Only root is able to do that. So, don't give them root access?


Yeah, but is there the way to user have root access and do not being allowed these commands?)


----------



## SirDice (Apr 3, 2018)

If you give them root access they can do anything and everything.


----------



## AlexRyshkov (Apr 3, 2018)

SirDice said:


> If you give them root access they can do anything and everything.


Ok, then i have a more specified question, how can i allow the user to poweroff the system and forbid to reboot it? i have already searched throuth the login.conf and didn't find anything connected with this...


----------



## aaron (Apr 3, 2018)

Yes. With `sudo`. You can disallow commands in the `/usr/local/etc/sudoers` file. Just make sure to exclude commands that allow them to get root. For example: `sudo su` or `sudo visudo` or `sudo` any shell on the system.


----------



## SirDice (Apr 3, 2018)

There's no real difference between the two. You typically don't use the poweroff(8) or reboot(8) commands but use shutdown(8). If the shutdown(8) command is allowed the machine can be halted, powered off or rebooted.


----------



## Sensucht94 (Apr 3, 2018)

AlexRyshkov said:


> Ok, then i have a more specified question, how can i allow the user to poweroff the system and forbid to reboot it? i have already searched throuth the login.conf and didn't find anything connected with this...




Install security/doas, refer to doas(1) and doas.conf(5), then touch a /usr/local/etc/doas.conf file, with a content similar to this:


```
permit nopass keepenv :wheel
deny username as root cmd reboot
```

This will allow members of wheel group to execute commands with elevated privileges, keeping their default environmental variables (instead of acquiring root's), and without being prompted for a password.  The $user specified after 'deny' will be hold back from executing `/sbin/reboot` even when passing doas beforehand and returned a `doas: Operation not permitted` error after a failed  attempt.  If any of those settings is not ok fro you, just remove 'nopass', 'keepenv', replace the group, etc...

Now uninstall sudo (and use doas from this point on if this is ok for you), or edit sudoers in order to prevent the interested UID/GID from using sudo at all

If you wanted to forbid poweroff too, you could also just exclude /sbin folder from interested user's $PATH, while running doas:


```
permit setenv { -ENV PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin/bin} username as root
```


----------



## rigoletto@ (Apr 3, 2018)

AlexRyshkov said:


> Yeah, but is there the way to user have root access and do not being allowed these commands?)





AlexRyshkov said:


> Ok, then i have a more specified question, how can i allow the user to poweroff the system and forbid to reboot it? i have already searched throuth the login.conf and didn't find anything connected with this...



Add the user to the operator group with you want that to be able to use shutdown(8). 

That will not prevent them to reboot but you can do that in the way Sensucht94 already told you.


----------



## shepper (Apr 3, 2018)

security/sudo can also acomplish this.  In sudo example, the access to various root commands can be fully specified; ie /sbin/shutdown -p now will only allow shutdown/poweroff.  I'm not sure doas is as specific.   You can also create a user shutdown group and have more control over which users can shutdown.


----------



## ShelLuser (Apr 4, 2018)

Still, despite the fact that these are all legit solutions they also ignore one very important aspect: if you don't trust someone to use the right command(s) then you shouldn't be giving them root access in the first place. Not even through some nifty tool such as Sudo or DoAs.

Security begins with applying a legit security scheme. And trying to deny a root user access to specific aspects of system management isn't one because basically it's not possible to do so (note: not even with those tools; you're not restricting the root user, you're handing limited privileged access to regular users).

I'm well aware that this may seem like nitpicking, but it's just the kind of nitpicking you have to do if you're after server security.


----------

