New answers tagged

0

Physical security is security. You have three options: Log in as root, either from the console or by ssh. Boot in single-user mode, which traditionally doesn't need the root password (but might on your system). Mount the disk image from another OS. Any of these will give you the ability to change the ownership of any file on the disk. If none of ...


2

Chroot is the more traditional way of doing this, and you can make it work, but since you're doing this via a web interface, it gets a little complicated: you must prevent race conditions (multiple users from using the same chroot environment), you must dynamically build a directory structure for each request, and probably a few other things I can't think of ...


0

As suggested by Drav Sloan you can use su like: su -l kent-server -c 'cd /home/kent-server/mc/ && screen -d -m -S Minecraft Java -jar -Xmx5120M -Xms5120M spigot.jar' It is also possble to ahcieve a similar result using sudo such as: sudo -u kent-server /home/kent-server/mc/spigot.sh


1

I think I can improve on the answer given by EightBitTony. ssh -t user@target 'sudo cat /source/file' > output && chmod +x output When more than one file is involved, I find pax much easier to use than rsync, not matter how often rsync is "simplified" for me. ssh -t user@target 'cd /src && pax -w ./' | pax -r HTH.


3

The general sense of @rui-f-ribeiro remark is correct, but the details are not. Details matter. Ubuntu uses these packages: iputils-ping passwd The ping utility resets permissions in a function named limit_capabilities, shared by ping and ping6. The relevant chunk of code looks like this: if (prctl(PR_SET_KEEPCAPS, 1) < 0) { ...


6

As @schily says, in the ping utilility (and others), the root permissions are dropped after they are no longer necessary. This is done for security reasons. From ping.c - main() - the user is dropped with the getuid and setuid call. getuid() gets the current user, and root doing a setuid() will change the uid of the process. /* * Pull this stuff up front ...


3

The uid of the second process has been reset already because there is no need to be root anymore after the sockets have been opened. The passwd utility still needs root privileges when you checked. If you like to verify this, you will need to check the source-code as the reset of the uid may be done too fast to give others a chance to verify the uid before ...


0

ssh -t user@target machine sudo cp /source/file /target/file The -t creates a pseudo-tty, so that sudo can ask for a password. The ssh command takes an optional command (sudo cp .... in this case) which it executes on the target machine and then disconnects. You will get prompted for the sudo password (i.e. user@target's password). You can then run the ...


0

If you know the root password, you can run su -s /bin/bash to get a root bash shell. sudo -s /bin/bash should work too, and depending on how sudo is configured you'll either need to know only your own password or no password. You can then use chsh -s /bin/bash to change root's shell back to bash. BTW, it's generally a bad idea to change root's shell on ...


0

You cannot edit files from the Grub prompt (Grub can only read files, it doesn't have any write support). You need to boot Linux¹. If you can't log in normally, you can completely bypass the normal boot process and start just a kernel and a shell. At the Grub prompt, press e to edit the boot sequence, add init=/bin/bash to the end of the linux=… line, and ...


-2

Pls try sudo vi /etc/passwd And enter your currently logged user password. Also you can find shell correct path in /etc/shell And to check current shell pls try echo $SHELL


1

You should remove from the password file the which word... It should be something like : root:x:0:0:root:/root:/bin/zsh Where /bin/zsh is the path to the Z shell binary. In the current config, the login process is trying to execute which zsh and that command is failing. Also, edit the file as root, with sudo vim /etc/passwd for example because it is ...


0

This is probably the result of cached authentication credentials being recycled in your sudo invocations. Try using sudo -k <some_allowed_command> and see if that gets you the behavior you expect.


1

SystemTap 3 lines, problem solved, SystemTap completely rules: Install SystemTap, create ptysnoop file: #!/usr/bin/stap probe kernel.function("pty_write") { if (kernel_string($tty->name) == @1) { printf("%s", kernel_string_n($buf, $c)) } } Make it executable. Now to watch /dev/pts/6 you just: $ sudo ptysnoop pts6 Edit: other ...


1

You can specify multiple file descriptors for peekfd. e.g. peekfd -n -8 -d -c 24184 0 1 2 will snoop on stdin, stdout, and stderr of pid 24184. The -c option will also attach to any child processes. This is necessary in order to see the ouput from them (e.g. seeing the output of ls that has been run in a snooped-on shell process) Strangely, I find ...


1

Start another Linux VM, and mount that disk to repair the problem. In addition, to avoid the password entered in single user mode, change as follows /lib/systemd/system/rescue.service. --- /lib/systemd/system/rescue.service.orig 2015-11-20 13:49:03.000000000 +0900 +++ /lib/systemd/system/rescue.service 2016-04-11 15:58:31.002000000 +0900 @@ -18,11 ...


0

A quick way to bypass this would be (assuming appropriate sudoers rights) to prefix the appropriate command with sudo, e.g. sudo system-config-users Otherwise, with some digging: % ls -l =system-config-users lrwxrwxrwx 1 root root 13 Jul 24 2015 /usr/bin/system-config-users -> consolehelper Which with some yet more digging turns up the userhelper ...



Top 50 recent answers are included