New answers tagged

2

To resolve the error message, you may need to install sudo using the steps below. Alternatively, you could run the command after logging in with the root account using su -. To install sudo: Log in with the root account using su -. Then, yum install sudo. After that is installed, add the user's account to the /etc/sudoers file. After the following ...


1

"root" (aka "superuser") is the name of the system administrator account. The origins of the name are a little archaic, but that doesn't matter. Root user has user id 0 and nominally has unlimited privileges. Root can access any file, run any program, execute any system call, and modify any setting. (But see below¹). Prior to the invention of the "sudo" ...


2

To give Tim access to iptables, you can edit /etc/sudoers, with visudo: tim ALL=NOPASSWD: /sbin/iptables This will allow him to used the iptables as root without inputing his password. The path is full, for security reasons, otherwise if only iptables as you have, Tim would be able run any binary called iptables as root, and would be enough to create a ...


2

Let´s say you want to allow users bellonging to group users2 to do some privileged control over apache without giving them root privilege. Add to /etc/sudoers %users2 keep ALL=NOPASSWD: /sbin/service http,/etc/init.d/http,/usr/sbin/apache2ctl If you just want them to restart apache it will be: %users2 ALL=NOPASSWD: /sbin/service http restart,/etc/init.d/...


3

Configuration is OK, but you need to have some identities in your ssh-agent to be able to authorize the sudo operation. You can verify that your agent has some identities using ssh-add -L It should print the public keys in your agent and at least one of them should match the public key on server in /etc/security/authorized_keys. If the agent does not ...


3

This is wrong syntax in bash: nohup ./NEW_SCRIPT_NAME.sh & && rm NEW_SCRIPT_NAME.sh From Shellcheck: Line 1: nohup ./NEW_SCRIPT_NAME.sh & && rm NEW_SCRIPT_NAME.sh ^-- SC1070: Parsing stopped here. Mismatched keywords or invalid parentheses? You can not simply run something & && something, ...


1

On a hardened server, you want as few setuid/setgid binaries, especially such that can be run by a user account that does not need the particular tool, as possible - for one simple reason: You do not absolutely trust these tools to police what someone does with them. Bugs in such programs or their dependencies that allowed users to circumvent such policing ...


3

Depending on your users, that may be a good or bad idea. The su command can be used by ordinary users to log into any other account, not just the superuser's, provided they know the password of the account. This is useful e.g. when two users are cooperating on a project, one of them (userA) is logged in and they need to read a file only accessible to the ...


15

The purpose is to prevent ordinary users from running the su command (su is similar to sudo, the difference being that sudo executes one command, su starts a new session as a new user, which lasts until that user runs exit) The default mode of su is 4755 or rwsr-xr-x, the "s" means that the command is set-UID (which means that it always runs as the user who ...


0

It is working after replacing * * * * * /home/anmol/display-notif.sh with * * * * * sudo -u anmol /home/anmol/display-notif.sh


1

The simple but accurate explanation is that the vendors of iOS and Android don't want the end-user to have full control over the operating system, whereas the vendors of Unix systems do. It's a design decision by the device vendor. It is technically possible to have iOS or Android systems where the end-user has full control. There is no such iOS-based ...


2

The problem is that you have a sudo configuration which allows running a login shell, but not directly running an arbitrary program. If the user has a restricted account, i.e. if the user's login shell is a program that only performs a few specific commands, then this is a security restriction; allowing you to run bash would bypass that security restriction....


-1

Your other questions at http://stackoverflow.com/questions/37753783/ and Is there any way to tell if a shell script was killed with signal 9 indicate that what's missing from your question is that you are trying to run Tomcat under upstart. In such a case: start-stop-daemon is not appropriate. Nor is su. Nor are Poor Man's Daemon Supervisor gyrations to ...


-1

Make sure that /etc/sudoers is not using secure_path or env_reset. You might also try using: sudo -E -u user # -E overrides env_reset. I don't understand the widespread use of "sudo su .." it's redundant. sudo -i : run an interactive login shell (reads /root/.bashrc and /root/.profile) sudo -s : run a non-login interactive shell (reads /root/.bashrc)


3

The -s switch for su command is to change the shell of the specified user. The command you want to run must be preceded by -c switch. So the command you are looking for is something like this: su -s /bin/bash -c "$CATALINA_HOME/bin/catalina.sh run" tomcat


3

If you're running su as root, you can use -s to specify a different shell (running as root is necessary here since your tomcat user doesn't have a valid shell), and -c to specify the command to run: su -s /bin/sh -c "$CATALINA_HOME/bin/catalina.sh run" tomcat You might find start-stop-daemon useful; it has a whole slew of options to specify the user and ...


6

As you determined, sudo is set up to only allow sudo su - kshitiz, so your second command is bound to fail. In any case, you're not going through the same user transitions. sudo su - kshitiz runs su - kshitiz as root; if you can sudo to root with no password, this will not ask for a password at all since su - as root changes users without asking for a ...


0

The user that's used in the build step is the user that was used to connect the slave. (For the master, it's the user id under which the master is running). So, create a slave that connects via ssh as the user that you need (possibly to localhost), and then run the jobs on that slave.


0

Solution as root by adonis' /etc/sudoers, I did gedit /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # Defaults env_reset Defaults mail_badpass Defaults ...


0

An interesting alternative is to run FreeIPA or IdM to manage your users and sudoer rules centrally. You can then create sudo rules and assign the option !requiretty in the rule. The command will then run as expected. You will also have the benefits of managing all the servers and users from a single set of configurations.


2

You need to watch out for the following two points: sudo gives the highest priority to the last matching configuration-line you need to separate different commands by ',' so your configuration-line has to be %sudo ALL= NOPASSWD: /usr/bin/pm-suspend, /usr/bin/gnome-session-quit


1

The full strace in your pastebin link shows that sudo is trying to open libnss-sss.so.2: open("/lib64/libnss_sss.so.2", O_RDONLY|O_CLOEXEC) = 8 That's an NSS module for SSSD - System Security Services Daemon, which manages access to various remote authentication services. Check that the SSSD is installed and running. If it is, then try following the ...


0

Somehow it was related to the id_rsa.pub file. For the root user, it didn't make a problem, but for sudo through root, it apparently does not work. Perhaps it is a particular case with root that blocks this or perhaps it needs another special permission, other than the recommended ones or group configuration. The "solution" was to just remove the public ...


4

Like @Serge pointed out in a comment, this line debug1: Offering RSA public key: /root/.ssh/id_rsa in your ssh -v output tells you that ssh tried to authenticate with the public key in root's home directory (/root) and not your own user directory (/home/yourusername). This leaves you with three options. You can either run ssh with the -i option to ...


-2

I think you need to check sudoer file and add the user through root privileges. The sudoers file located at: /etc/sudoers(depends on linux base), contains the rules that users must follow when using the sudo command. Read out for suoders for you version of Linux/Unix. you will get lot of material on web which definitely help you out https://www.garron....


0

Yes, there is a way to restrict this behaviour. This behaviour of su is governed by the PAM module (Plugable Authentication Module): You must edit /etc/pam.d/su comment the line : auth sufficient pam_rootok.so like this: #auth sufficient pam_rootok.so after that su from root will ask for the user password.


1

Use a shell script instead of an alias. in ~/.bashrc: export PATH="$PATH":~/bin your script in ~/bin/runthat: #!/bin/bash sudo nohup /path/to/binary > /dev/null 2>&1 & Then to run it, just do it like: $ runthat Or if you skipped the PATH step, then run it like: $ ~/bin/runthat If this is a system-wide (all users) script instead of ...


4

Package managers need to run as root because what they do affects all users. IMO package managers should require sudo only when writing files to a dir owned by root. like /bin or /etc. They also require root access to manage the database of installed packages. A package manager that installs software under a user's home directory doesn't need to run ...


1

After some searching, I found that I needed to open /etc/dnf/dnf.conf and add the line proxy="http://<my_proxy>:<port> Simply setting the http_proxy in the bash shell was not enough.


2

Note that while you could edit the sudoers file (using visudo in a terminal as root), what you probably actually want to do is add yourself to the wheel group. See How to make Fedora user a sudoer? for details, but in short, this group is predefined as having sudo-for-everything privileges and is our standard "admin" group. (If you check the "make user an ...


0

Package manager is a powerful tool to repair&destroy system. It's easier to ask root privilege once when check all actions for permission.


1

You able to set sudo chmod +x /usr/bin/* It's a little strangely that files in bin are not executable be default. For example in my ubuntu: $ ls -la /usr/bin/ ... rwxr-xr-x 1 root root 14768 апр 15 01:19 zdump -rwxr-xr-x 1 root root 10384 янв 31 02:14 zeisstopnm -rwxr-xr-x 1 root root 206000 фев 24 17:31 zeitgeist-daemon -rwxr-...


1

Removing setuid/setgid from system applications isn't done routinely (though there are occasional guidelines which do suggest just that). Doing this invalidates the package configuration, making it necessary for someone to make special-cases when investigating discrepancies between package content and the installed system. The usual approach is to not ...


1

Matching Defaults entries for xxxxx on this host: …, noexec, … The user xxxxx is allowed to run any program, but this program isn't allowed to run any other program. There are exceptions when running commands as root. As a security restriction, this makes no sense: if you can run any program then you can e.g. run passwd and change the password on the ...


11

Looks like you missed something. From the Debian documentation: 6.3.2. Setting Up Users And Passwords Just before configuring the clock, the installer will allow you to set up the “root” account and/or an account for the first user. Other user accounts can be created after the installation has been completed. 6.3.2.1. Set the Root Password ...



Top 50 recent answers are included