If we want all users of the "admin" group to be able to run every command as root, we can modify our example:īob can still do his stuff, and alice is now allowed to run sudo, with the same rights, with her password. Let's start with bob and alice, members of a group named admin. Let's go back to our sudoers file (which is, by the way, well commented on CentOS 5). We can allow a user or group of users to run only one command, or a group of commands. This password is bob's password, and not root's password, so be careful when you give rights to a user with sudo.īut sudo can do more. Save (press escape, then type ZZ), and you are ready to go. So, the quick and dirty way to use sudo would be to add at the end of the sudoers file : If you are on a desktop computer, you will want to be able to do almost everything. Basically, it runs $EDITOR (vim as default) on /etc/sudoers, but it is not recommended to do it manually. Once sudo is installed (package name: sudo), you can configure it by running 'visudo' as root. Thanks to sudo, you can run some or every command as root. You don't need to be root every time you want to run some specific administrative tasks. So you either need to specify the full PATH to the command if you just used 'su' (eg, /sbin/ifconfig) or use 'su -' when becoming root. For a more detailed explanation, see the bash manual page (man bash), particularly the section on INVOCATION and login shells. When you become root by using 'su -', you also adopt root's PATH whereas using just 'su' retains the original user's PATH, hence why becoming root using just 'su' and trying to run a command located in /usr/local/sbin, /usr/sbin, or /sbin results in a 'command not found' error. However, root commands are mostly located in /usr/sbin, and /sbin and occasionally /usr/local/sbin As such, root's PATH reflects this. In debugging WHY a given binary cannot be seen, it is helpful to view the currently effective PATH with: echo $PATHĬommands for regular users are mostly located in /usr/bin, and /bin and occasionally /usr/local/bin - the /usr/local/* path prefix is not used for packaging by default upstream. Often when a person reports a problem, in IRC or otherwise, they are referred to this page. It starts searching each directory on the PATH until a match is found. When you type a Linux command, the shell will search the user's PATH to try to locate the command to run. The reason is that regular system users and the root user have different PATH environment variables. Often a user will become root using just 'su', try to run a command (eg, ifconfig), and get a 'command not found' error. 'su ' gives the current user the identity of whereas 'su - ' gives the current user the identity of together with 's environment that would be obtained by logging in as. If no username is specified, then the root user is assumed, so the above is often shortened to:īut the two commands above behave differently. The su command takes the following format:īut most commonly we will use su to become the root user: To do this, we can use the su command (substitute user). Many commands can only be run as the root user so to run these commands we need to become "root". The addgroup/useradd machinery allows user-ownership of any files/directories created by the build. Where cross_compile.sh is the script shown above. With this a user can simply do something like: cd /path/to/target_softwareĬross_compile.sh "mkdir build cd build cmake. I am using this workflow to allow my dev-team to cross-compile C/C++ code for the arm64 target, whose bsp I maintain (the my-docker-image contains the cross-compiler, sysroot, make, cmake, etc). Note how the user's current working directory is volume mounted This allows the user to run arbitrary commands using the tools provides by my-docker-image. Docker run -v $(pwd):/cmd -rm my-docker-image "bash /cmd/$(basename $)"
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |