That entry ensures that root can run sudo. If you comment it out,
run as root will fail.
It’s a convenience: it means users can run sudo commands without thinking about things too much, i.e. they’ll work the same way whether they’re running as a sudo-enabled user or root (whether that’s a good idea is another question). It also means that scripts ...
Your file will be fine.
Renaming a file will not alter the file's contents in any way whatsoever.
In fact, you would still be able to successfully extract the contents of your compressed tar archive using
tar -xvz -f opt
where opt is the name you accidentally gave the file. Renaming it to its original name would obviously be of help to you for knowing ...
The idea behind setting /etc/shadow permissions to 000 is to protect that file from being accessed by daemons, even when running as root, by ensuring that access is controlled by the DAC_OVERRIDE capability. Since Fedora 12 and RHEL 6, Fedora-based systems run daemons without DAC_OVERRIDE, but grant DAC_OVERRIDE to administrator login sessions (so that the ...
In the absence of a hashbang, /bin/sh is likely being used. Some POSIX shells do support the ++ and -- operators, and ((...)) for arithmetic evaluations, but are not required to.
Since you have not included a hashbang in your example I will assume you are not using one and therefore your script is likely running in a POSIX shell that does not support said ...
The shell expands ~ before running sudo; you can see this in action with set -x:
$ set -x
$ sudo ls ~
+ sudo ls /home/skitt
which shows that the command actually run already has the home directory expanded, using the current user at the time of the expansion.
To see the target user’s home directory, you have to defer the tilde expansion:
sudo bash -c 'ls ...
sudo allows users to execute commands as UID 0 (or other users) based on how it’s configured. There is no need to ask root for a password to run a command as UID 0, because it already is UID 0.
Furthermore, root can also su to anyone it’d like, so there’s no need to prompt for a password when executing sudo -u user as UID 0.
Note: I do believe there is a ...
Most Linuxes I've seen are configured so that passwd doesn't ask root for the old password:
root@xxx ~# passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Even if passwd does ask for it, you could try chpasswd, or edit /etc/passwd and /etc/shadow by hand (the password hash is the second field, the long ...
The premise of the question is mostly flawed. Linux does treat user 0 as the superuser. (It was always user 0; calling that user root is just a convention.) Capabilities are an additional mechanism that allows non-root processes to receive specific privileges. User 0 normally effectively has all the capabilities, so root remains the superuser.
A process ...
A directory readable by only root on your system would be readable by root on anyone else's system too.
If the physical security of the system is compromised, only encryption would possibly protect the data.
Note that a user with physical access to a machine may also choose to boot the system into single-user mode to access files as root, without ...
This is an example, but it wasn’t picked out of thin air: marc is Marc Ewing, who created Red Hat Linux and wrote the initial version of the /etc/aliases file which ends up in CentOS.
The line is commented out, so it doesn’t have any effect; if you want to redirect email sent to root, it’s up to you to choose whatever recipient is appropriate, correct the ...
If I have read your question correctly you seem to be stuck on the fact your mac does not have matching usernames (including root) with your server.
You really don't need to use a matching username on the client when logging into or setting up access to a server. If you don't specify a username then the ssh client will assume your current username, but you ...
While this is an interesting inconsistency. It would be pointless in stopping root, as root has capabilities CAP_SETUID and CAP_SETGID, so does not need sudo. It can do what ever it want.
If sudo is checking root, and not these capabilities, then there may be a latent-bug: root with no capabilities could escalate (I don't know I have not looked at the code, ...
Your code has syntactic issues. There must be a space after [ and in front of ] in the test:
read -p "What is your name?:" ANSWER
if [ "$ANSWER" == "root" ]; then
echo 'Hello, administrator'
printf 'Hello, %s\n' "$ANSWER"
Additionally, you may want to use the id utility to get the UID of the user. The root user always has a UID of zero:
I usually have moderate success retrieving lost root MySQL passwords from MySQL history logs (e.g. .mysql_history log files). Also frequently applications are also a data trove for finding privileged passwords. Often root passwords are (mis)used for applicational use. Also, more rarely, as @Luciano says, you can also found MySQL password(s) in the shell ...
No, you don’t need to log in to start a process running as a given user. Logging in is a user-space construct; the kernel doesn’t care about that. There are multiple examples of this; for example, cron jobs can run as any user, without that user being logged in.
To address your specific questions:
no, root doesn’t need to log in to start the init process, ...
Run the read side of rsync as a dedicated non-root user but with the capability CAP_DAC_READ_SEARCH. The user should have a full view of the filesystem (of course) and access to a copy of /usr/bin/rsync which has this capability. I'm not very familiar with capabilities on Linux but I think this is how to set it up:
cp /usr/bin/rsync /usr/local/sbin/rsync-...
Once you define the sudoers specification with the 'ALL' keyword in the commands field, there is no way to effectively prevent the execution of a specific command or set of commands. The sudoers manual explains this in a straightforward manner:
Limitations of the ‘!’ operator
It is generally not effective to “subtract” commands from ALL using
I suspect this is happening because you’re running your program from a terminal which isn’t a virtual console. /dev/tty is a special device which provides access to the controlling terminal, and that’s not necessarily a virtual console; but the ioctl you’re using only works on virtual consoles.
Your program will work reliably if you ensure that fd points at ...
Not sure if it helps, but I had similiar problems (hitting ok and nothing happens) when setting up backintime to backup to a ssh destination. To narrow down the problem, I would do the following:
Check that your user has read and write access to /mnt/backup
run backintime-qt4 from the commandline to see if any errors are reported there
run journalctl -f ...
Why do you want to do that? I don't see any potentially worthwhile point to that.
You won't lose your machine from doing that, but you'll make it a little harder to change permissions (anybody who'll want to do that will have to find - or make - another program that performs the chmod(2) system call.
I would recommend against doing that, and if you have ...
If you remove execute permissions from the chmod binary, then all shell scripts (including Makefiles!) that try to execute it will get an error when they try. This includes countless administrative and installation scripts. Your system will fail to work correctly in many unforeseen ways.
Actual programs that call the Unix syscall directly instead of exec’...
If you do crontab -e then you're modifying the per user cron entry, typically in /var/spool/cron/crontabs/$USERNAME.
Because these are per-user, they don't have the requirement for a username.
So the entry would look something like
00 4 * * * /sbin/shutdown -r now >> /var/log/daily-backup.log 2>&1
In contrast, the /etc/crontab (and files in /...
The password lines in PAM configuration only take effect when you're trying to change your password. So your /etc/pam.d/common-password modification is extremely unlikely to be a factor in you not being able to switch to root using sudo.
If you had made any changes to PAM configuration lines beginning with keywords auth, account, or session, then it would ...
Q1. Can an attacker gain root on my host OS using only the NET_ADMIN capability?
Yes (in some cases).
CAP_NET_ADMIN lets you use the SIOCETHTOOL ioctl() on any network device inside the namespace. This includes commands like ETHTOOL_FLASHDEV, i.e. ethtool -f.
And that's the game. There is a little more explanation in the quote below.
SIOCETHTOOL is ...
Correction to the first part of my answer even though another answer has been accepted:
It's not entirely random but Marc Ewing, the creator or Red Hat and writer of the initial /etc/aliases (just providing to give clarity).
If you'll notice, the line is commented out.. If you wanted to set an alias for mail going to root then you'd uncomment the line and ...
From the offical documentation:
User management in Raspbian is done on the command line. The default user is pi, and the password is raspberry.
You won't normally log into the computer as root, but you can use the sudo command to provide access as the superuser. If you log into your Raspberry Pi as the pi user, ...
The simplest way to do this is:
manually copy the ~7GB of files from the /home filesystem to an external media device
delete the /dev/sda7 partition
increase the size of the /dev/sda6 partition
grow the ext4 filesystem on /dev/sda6
create a new /dev/sda7 partition in the remaining space
format the new /dev/sda7 partition with an ext4 filesystem
copy the ...
Ever since version 2.4 of the Linux kernel, there's no advantage to having a separate swap partition if you only have one OS, so most folks just create a swap file when installing Linux, and put that in /root. So, you really only need /root.
(If you have multiple Linux OS, then each would have its own swap file, but could share one swap partition, so in ...
You can resolve this issue by creating a normal user for login, and then using a local escalation tool (su, sudo, doas, pkexec...) to gain root privilege.
OpenSSH (like many other tools) does not restrict root based on the string "root", but rather on the privileged UID zero. Since you have set the UID of your new user to zero, it will fail to login in ...
I'll take a stab at this answer. The OP did not say what OS is being used, so I will be somewhat generic.
First, make a file called _free_os_cache.sh_
# Forces the OS to clear OS caches
# Run a sync to reduce dirty caches
# Tell the OS to not make warnings
echo 4 | tee /proc/sys/vm/drop_caches
# Tell the OS to clear caches