A A
asked on
allow user for readonly config or readonly commands in linux and prevent editing or changing any files config or linux settings
Hello experts
I have user that have root access by switching sudo su - to root as I want to withdraw user access as sudo and add it only permission as read only for config files or commands as ls-la
df-dk ,...etc without letting user being able to make any changes to linux machine so tobe read only group for all commands and all config files.
waiting for your kind advice
I have user that have root access by switching sudo su - to root as I want to withdraw user access as sudo and add it only permission as read only for config files or commands as ls-la
df-dk ,...etc without letting user being able to make any changes to linux machine so tobe read only group for all commands and all config files.
waiting for your kind advice
Are you sure that the files aren't already globally readable?
Most of the files in /etc can be read by a normal user. If you find any file that normal user can't access, you can change the file permission as required.
ASKER
how can I prevent sudoers user by sudo su - and entering their password to be root and leave other users with sudo su -
Allowing `sudo ls` and `sudo cat` will give them 99% of what they need.
`sudo tail -f` is also useful.
`sudo find` is risky, as the -exec options would allow them to modify files. Though it's possible to write a wrapper script that disallows those options.
`sudo view` is no good, as `view` allows you to force-write files or open a subshell as root
With those basic commands & pipes or redirection, more complex yet safe commands can be constructed:
`sudo cat file |grep {pattern}` executes cat as root but grep as the unprivileged user.
(this would normally be a Useless Use Of Cat, but has a purpose here)
`sudo cat file > /tmp/file_copy` makes a copy they can then edit as the unprivileged user
(I'm not sure if they can "escape" the ">" to allow overwriting read-only files!)
`sudo tail -f` is also useful.
`sudo find` is risky, as the -exec options would allow them to modify files. Though it's possible to write a wrapper script that disallows those options.
`sudo view` is no good, as `view` allows you to force-write files or open a subshell as root
With those basic commands & pipes or redirection, more complex yet safe commands can be constructed:
`sudo cat file |grep {pattern}` executes cat as root but grep as the unprivileged user.
(this would normally be a Useless Use Of Cat, but has a purpose here)
`sudo cat file > /tmp/file_copy` makes a copy they can then edit as the unprivileged user
(I'm not sure if they can "escape" the ">" to allow overwriting read-only files!)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi david
what about 1-if I like user not to use sudo su - and will able to read all configuration for view only
2- another suggestion to let user read all configuration but when do sudo su - it will be asked for root password
waiting for your kind experienced advice
what about 1-if I like user not to use sudo su - and will able to read all configuration for view only
2- another suggestion to let user read all configuration but when do sudo su - it will be asked for root password
waiting for your kind experienced advice
1-if I like user not to use sudo su - and will able to read all configuration for view only...
This is what the chmod ugo+r /path command solves.
My rule is anyone can read anything, except sensitive data.
This minimizes the requirement for adding uses to the sudo group.
2- another suggestion to let user read all configuration but when do sudo su - it will be asked for root password
This is how su + sudo work, they prompt for a password.
This is essential security.
If you disable this, anytime any sudo group user is hacked, the hacker has instant root access to the entire machine/container/VM.
Do not under any circumstance try to defeat password prompting.
Can you disable password prompting? Yes.
Should you? Only if you'd like to be have no clue what happened each time your machine is hacked.
This is what the chmod ugo+r /path command solves.
My rule is anyone can read anything, except sensitive data.
This minimizes the requirement for adding uses to the sudo group.
2- another suggestion to let user read all configuration but when do sudo su - it will be asked for root password
This is how su + sudo work, they prompt for a password.
This is essential security.
If you disable this, anytime any sudo group user is hacked, the hacker has instant root access to the entire machine/container/VM.
Do not under any circumstance try to defeat password prompting.
Can you disable password prompting? Yes.
Should you? Only if you'd like to be have no clue what happened each time your machine is hacked.