New answers tagged

0

I cannot explain what exactly fails in your example (so I admit it is some kind of voodoo programming on my side), but this is a fix that (almost -- see below*) works in my bash (Debian): get rid of inside echo; escape $2. Result: echo password | su -c "ps aux | grep verySpecificChain | grep -v grep | /usr/bin/awk '{ print \$2 }' | xargs kill" userName; ...


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 ...


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 ...


1

Under GNU/Linux at boot, you should not use su (as it depends on PAM/dbus, which may not be available yet), but runuser: runuser username -l -c "screen -S sessionname -d -m /path/to/bash/script" When using runuser followed by the user name, the syntax is the same as su.


2

The reason for this behaviour is documented in the manual page for recent versions of su: -c, --command COMMAND Specify a command that will be invoked by the shell using its -c. The executed command will have no controlling terminal. This option cannot be used to execute interractive programs which need a controlling TTY. (emphasis mine) ...


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 ...



Top 50 recent answers are included