If you take a look at the executable sudo:
$ which sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun 3 2011 /usr/bin/sudo
You'll notice that it carries the permission bits ---s--x--x. These can be broken down as follows:
- - first dash denotes if a directory or a file ("d" = dir, "-" = file)
--s - only ...
That is the "setuid" bit, which tells the OS to execute that program with the userid of its owner. This is typically used with files owned by root to allow normal users to execute them as root with no external tools (such as sudo).
You can set the suid bit using chmod, eg chmod 4755 which will give a file give the normal permissions 755 does (rwxr-xr-x) ...
When executing shell scripts that have the setuid bit (e.g., perms of rwsr-xr-x), the scripts run as the user that executes them, not as the user that owns them. This is contrary to how setuid is handled for binaries (e.g., /usr/bin/passwd), which run as the user that owns them, regardless of which user executes them.
Check this page: https://access.redhat....
You don't need to give sudo access to echo. In fact, that's pointless because, e.g. with sudo echo foo > bar, the redirection is done as the original user, not as root.
Call the small script with sudo, allowing NOPASSWD: access to ONLY that script (and any other similar scripts) by the user(s) who need access to it.
This is always the best/safest way ...
It's mainly a matter of what the tool or program does. Keeping in mind that a non-superuser can only touch files that it owns or has access to, any tool that needs to be able to get its fingers into everything will require superuser access in order to do the thing which it does. A quick sample of Things that might require superuser access include, but are ...
FUSE and its access rights
lsof by default checks all mounted file systems including FUSE - file systems implemented in user space which have special access rights in Linux.
As you can see in this answer on Ask Ubuntu a mounted GVFS file system (special case of FUSE) is normally accessible only to the user which mounted it (the owner of gvfsd-fuse). Even ...
Sudo and the /etc/sudoers file aren't just for granting users full root access.
You can edit the sudoers file with an existing sudo user, with the command sudo visudo
You can group the commands that you want to grant access to like below:
Cmnd_Alias SHUTDOWN_CMDS = /sbin/poweroff, /sbin/halt, /sbin/reboot
Cmnd_Alias UPDATE_COMMANDS = /usr/bin/apt-get
I'm going to use Firefox as an example, because its open source and easy to find the information for, but this applies (probably with slightly different lists of ports) to other browsers, too.
In August 2001, CERT issued a vulnerability note about how a web browser could be used to send near-arbitrary data to TCP ports chosen by an attacker, on any ...
acess denied to root:
root can be denied direct network access. This is useful on internet connected hosts, as it requires that you login as smith, then sudo.
some stuff root can't do:
This is NOT for a lack of privilege. I can't see anything root couldn't do, however some technical issues might be experienced as "forbidden".
I am root, why can't I ...
Give the other users permission to kill the processes as the low priority user through
sudo -u lowpriouser /bin/kill PID
A user can only signal their own processes, unless they have root privileges. By using sudo -u a user with the correct set-up in the sudoers file may assume the identity of the low priority user and kill the process.
ping needs root so it can open a socket in raw mode. That's literally the first thing it does when it starts up:
icmp_sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);
socket_errno = errno;
That's the only thing it needs root for, so like many programs, it immediately drops its privilege level back to your normal user account:
uid = getuid();
sudo is a a normal application with the suid bit. This means in order to use sudo it has to be installed on the system. Not all Linux systems have sudo installed per default like for example Debian.
Most Android systems are targeted for end users who don't need to know the internals of Android (i.e. each Android applications runs under it's own user), so ...
You have a way simpler solution, just run: su -s /bin/bash nobody (replace /bin/bash with the shell of your choice).
The This account is currently not available. error is due to the fact that nobody user default shell is /usr/sbin/nologin, su -s force the system to use another shell.
You should read the Arch Wiki page on sudo.
sudo ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.
You can install sudo from the repositories and then ...
There are plenty of ways for an unprivileged user to slow down a system and running sync is far from being the more efficient. On the other hand, having the file systems data committed to disk is quite a legitimate request so forbidding users (and thus their processes) to do it would be excessive.
In any case, I disagree about your "unnecessary disk writes" ...
The 9.04 release was supported until October 23 2010. The vulnerability you found was reported in August 2009. It seems reasonable that, since the release was still current and supported at the time, the ISO was patched and what you downloaded was a version that is no longer vulnerable.
Furthermore, you seem to have demonstrated quite nicely that it isn't ...
Check the owner on the gpio files:
ls -l /sys/class/gpio/
Most likely, you'll find out that they are owned by group gpio:
-rwxrwx--- 1 root gpio 4096 Mar 8 10:50 export
In that case, you can simply add your user to the gpio group to grant access without sudo:
sudo usermod -aG gpio myusername
You'll need to logout and log back in after that ...
I think I should link here two answers from serverfault:
how do i duplicate the nobody user?
Create restricted user on Debian server
( btw, it was moved to serverfault from stackoverflow, just recently -- and possibly could have been moved to this site as well )
Basically -r means "set account as a system one" -- "no expiration", etc -- and the full ...
In linux, the privileges of root were at one point divided into "capabilities", so you can get a full listing of root's special privileges by looking into that documentation: man 7 capabilities.
To answer your question, a command will require running as root when it needs one of these privileges, and its non-script executable does not have the relevant ...
Running unprivileged containers is the safest way to run containers in a production environment. Containers get bad publicity when it comes to security and one of the reasons is because some users have found that if a user gets root in a container then there is a possibility of gaining root on the host as well. Basically what an unprivileged container does ...
sudo tcpdump -Z uses initgroups(3), setgid(2) and setuid(2) to drop the root privileges of its own process.
# code taken from:
/* Drop root privileges and chroot if necessary */
droproot(const char *username, const char *chroot_dir)
No, this isn't possible. You can set the immutable attribute with chattr +i, which will at least make it irritating and non-obvious what has to be done to allow writing to the file, but they can just unset it again. Also, your filesystem has to support this, and have the functionality enabled.
SELinux can also do some limiting, but again, it can be disabled....
su - alice
sudo vim /etc/hosts
From man su:
The su command is used to become another user during a login session.
Invoked without a username, su defaults to becoming the superuser. The
optional argument - may be used to provide an environment similar to
what the user would expect had the user logged in directly.
For more information, ...
The simplest way is to use the su(1) command, it has an option that allows you to run a command via the user's shell, example:
su foo -c ls
This will switch to the user foo and run the ls command. If the user you want to use does not have a valid shell (ie it's not in /etc/shells, like /bin/false or /sbin/nologin) you will also have to specify a shell on ...
lsof always tries to obtain some basic information about all filesystems, even if the arguments happen to imply that no result will come from a particular filesystem. If it's unable to access a filesystem (specifically, to call stat at its mount point, as the message says), it complains.
As root, you would normally have permission to access filesystems. ...
What you really want to do is to use SSH CA and sign keys used by each support person (they should have their own ssh keys, like passports) and configure your clients' servers to use the TrustedUserCAKeys /etc/ssh/users_ca.pub in the /etc/ssh/sshd_config. This way the server will accept any key signed by the CA key (which you have access to) and you will be ...
In the usual case, this is incorrect - the superuser has privileges / permissions to any functionality the system provides(1). Where this rule breaks down is when you throw SELinux into the mix. With SELinux, it is possible to restrict even root's privileges to disallow certain actions. However, the specific actions disallowed are highly dependent on the ...
You might know the normal read, write and execute permissions for files in unix.
However, in many applications, this type of permission structure--e.g. giving a given user either full permission to read a given file, or no permission at all to read the file--is too coarse. For this reason, Unix includes another permission bit, the set-user-ID bit. If this ...
First I'll discuss the setuid bit, which passwd uses and is distinct from the setuid() system call (which passwd does not use). There is perhaps some confusion in the question in this regard.
It is not a protection against a buffer overflow, it's vunerable to such, or basically anything which would allow an attacker to use a privileged process for some ...