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) ...
The setuid bit can be set on an executable file so that when run, the program will have the privileges of the owner of the file instead of the real user, if they are different. This is the difference between effective uid (user id) and real uid.
Some common utilities, such as passwd, are owned root and configured this way out of necessity (passwd needs to ...
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....
Here are the answers:
root has always full access to files and directories. The owner of the file usually has them too, but this is not always true. For example:
-r-xr----- 1 user1 users 199 Oct 14 18:42 otherfile.bin
user1 is the owner; however they can only read and execute, but root still has full access (rwx) to the file.
RUID is the Real User ID ...
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 ...
Every process in a UNIX-like system, just like every file, has an owner (the user, either real or a system "pseudo-user", such as daemon, bin, man, etc) and a group owner. The group owner for a user's files is typically that user's primary group, and in a similar fashion, any processes you start are typically owned by your user ID and by your primary group ...
In its most common configuration, sudo asks for the password of the user running sudo (as you say, the user corresponding to the process’ real user id). The point of sudo is to grant extra privileges to specific users (as determined by the configuration in sudoers), without those users having to provide any other authentication than their own. However, sudo ...
The explanation is kind of annoying: bash itself is the reason. strace is our friend (must be SUID root itself for this to work):
getuid() = 1000
getgid() = 1001
geteuid() = 0
getegid() = 1001
setuid(1000) = 0
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();
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 ...
For the compiled executable, from man 2 chown:
When the owner or group of an executable file are changed by an
unprivileged user the S_ISUID and S_ISGID mode bits are cleared. POSIX
does not specify whether this also should happen when root does the
chown(); the Linux behavior depends on the kernel version.
Reversing the chown and chmod order ...
In your first case, it's Bash that doesn't like being run as setuid.
If Bash is started with the effective user (group) id not equal to the real user (group) id,..., and the effective user id is set to the real user id.
See: Bash's manual on startup files, also Setuid bit seems to have no effect on bash .
In the second case, it's the order of chmod and ...
The problem is that setuid and setgid are not sufficient to give your process all the credentials it needs. The authorizations of a process depend on
its supplementary groups
See man 7 credentials to get a more detailed overview. So, in your case, the problem is that you correctly set the UID and GID, but you don't set the ...
Setuid and setgid (and setcap where it exists) are the only ways to elevate privileges. Other than through this mechanism, a process can relinquish privileges, but never gain them. Therefore you would not be able to do anything that requires additional privileges.
For example, the programs su and sudo need to be able to run commands as any user. Therefore ...
In order for ping to work it needs to be able to create a raw network socket. This is typically a privileged action.
On a modern Linux system this can be granted with "capabilities"
eg on CentOS 7:
$ ls -l /bin/ping
-rwxr-xr-x 1 root root 62088 Nov 7 2016 /bin/ping*
$ getcap /bin/ping
/bin/ping = cap_net_admin,cap_net_raw+p
On Debian 9.1 (Stretch):
You can't change other passwords because the program won't allow you to. The program has system permissions to change any password it wants, because it is running as root, but the program has been specifically designed not to give the user any way to get it to use those permissions.
It is not quite that the user becomes root temporarily, it is that the ...
Root is user 0
The key thing is the user ID 0. There are many places in the kernel that check the user ID of the calling process and grant permission to do something only if the user ID is 0.
The user name is irrelevant; the kernel doesn't even know about user names.
Android's permission mechanism is identical at the kernel level but completely different ...
sudo usually asks for the password of the user running it, though this can be configured:
Unlike su(1), when
sudoers requires authentication, it validates the invoking user's credentials, not the target user's (or root's) credentials. This can be changed via
the rootpw, targetpw and runaspw flags, described later.
Setting rootpw has sudo ...
Yes you can, but it is probably a very bad idea. Usually, you would not set SUID bit directly on your executable, but use a sudo(8) or su(1) to execute it (and limit who can execute it)
Note however, there are many many security problems with allowing regular users to run programs (and especially scripts!) as root. Most of them having to do that unless 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 ...
It's just a convention. All constant identifiers are associated with numbers in the Linux source code. Some of them are very old, and come from the very first releases of the kernel while others were added recently.
The constant S_ISUID associated with "setuid" is defined in include/uapi/linux/stat.h, one of the numerous Linux headers. It could have been ...
Most filesystems designed for Unix/Linux can be mounted with a nosuid attribute, which will prevent setuid or setgid binaries located on those filesystems from altering the effective uid or gid of a process. It's often used when mounting "untrusted" filesystems, those that are under the control of a non-administrator.
In your case, the filesystem you're ...
-rwsr-xr-x root root in the result of ls -l "$(type -p nano)" means it is setuid. As a result, whoever runs nano has root privileges. This is not expected and shouldn't be happening in any normal environment. Find out with your administrator what the point is.
Covering only runit and sudo misses a lot. There is actually a whole family of toolsets like runit, and a wide choice of tools for doing exactly this, the very task that they were designed for:
Daniel J. Bernstein's daemontools, has setuidgid: setuidgid user /home/user/unprivileged.sh
Adam Sampson's freedt has setuidgid: setuidgid user /home/user/...
Unix has the concept of real and effective UIDs (and GIDs for that matter).
When you run a setuid program then the effective ID of the process is set to the owner of the file.
So in the case of mount you have an effective ID of root. But you still have a real ID of user.
Programs such as passwd or su or mount can check the real ID to see who is running ...
What changed is that /bin/sh either became bash or stayed dash which got an additional flag -p mimicking bash's behaviour.
Bash requires the -p flag to not drop setuid privilege as explained in its man page:
If the shell is started with the effective user (group) id not equal to the real user
(group) id, and the -p option is not supplied, no ...
No, but the dynamic linker will ignore some environment variables when run with setuid as otherwise you could make it load and run any code as the target user. That goes for LD_LIBRARY_PATH, LD_PRELOAD and more. See ld.so(8).
I actually found the NoNewPrivileges= option that allows my process children to use the setuid().
From what they are saying, it is certainly not an option one should lightly choose to use. However, the default is: do not allow the setuid() feature. (what they mean by «elevate privileges».)
What worked for me was to do this: