Is there a way to know where command typed? I mean when I list the running processes, there are many processes with full path name, but it does not indicated where these process started.
Think about that there is a java application under /tmp/AppJava.jar It could be executed under /home/appuser or /home/test by manullay or other script.
Is there a way how to find java -jar /tmp/AppJava.jar executed under which directory?
Yes you can.
You need to find the PID of the process, and then
ls -l /proc/$PID/cwd
For example, my shell has current directory /home/igor:
$ ls -l /proc/$$/cwd
lrwxrwxrwx 1 igor igor 0 nov 11 21:49 /proc/6569/cwd -> /home/igor
The PID of the process you can find using ps:
$ ps aux | grep java.*AppJava.jar
Related
I'm trying to monitor command execution on a shell.
I need to separate the input command, for example:
input:
ls -l /
output:
total 76
lrwxrwxrwx 1 root root 7 Aug 11 10:25 bin -> usr/bin
drwxr-xr-x 3 root root 4096 Aug 11 11:18 boot
drwxr-xr-x 17 root root 3200 Oct 11 11:10 dev
...
Also, I want to do the same if I open another shell, for example, after connection through ssh to another server.
I've been using script command to do this and it works just fine!
It logs all command input and output even if the shell changes (through ssh, or entering a msfconsole, for example).
Nevertheless, I found two main issues:
For my project, I need to separate (using a decoder) each command from the rest, also it would be awesome to be able to separate command input and output, for example:
cmd1. pwd ---> /var/
cmd2. echo "hello world" ---> "hello world"
....
Sometimes the script command could generate an output with garbage due to shell special characters (for colors, for example) which I would like to filter out.
So I've been thinking about this and I guess I could create a simple script that read from the file written by "script" command and processed the data.
Nevertheless, I'm not sure about what could be the best approach to do this.
I'm evaluating different solutions and I would like to know different proposals from the community.
Maybe I'm losing something and you know a better tool rather than script command or have some idea I've not considered.
Best regards,
A useful util for distinguishing stdout from stderr is annotate-output, (install the "devscripts" package), which sends stderr and stdin both to stdout along with helpful little prefixes. For example, let's try counting characters of a file that exists, plus one that doesn't exist:
annotate-output wc -c /bin/bash /bin/nosuchshell
Output:
00:29:06 I: Started wc -c /bin/bash /bin/nosuchshell
00:29:06 E: wc: /bin/nosuchshell: No such file or directory
00:29:06 O: 1099016 /bin/bash
00:29:06 O: 1099016 total
00:29:06 I: Finished with exitcode 1
That output could be parsed separately using sed, awk, or even a tee and a few greps.
As title, I run the above commands in sh shell of Linux, but I just cannot find the the child processes of pid 7459 by running "ps -ef | grep dummy".
Can someone explain why there could be such difference between these 2 commands?
They are active processes ,not LWP(thread), right? How can I display the threads,btw?
sh-3.2$ pstree -p 7459
dummy(7459)-+-{dummy}(7508)
|-{dummy}(7528)
|-{dummy}(7529)
|-{dummy}(7530)
|-{dummy}(7551)
|-{dummy}(7552)
|-{dummy}(7553)
`-{dummy}(7554)
sh-3.2$ ps -ef | grep dummy
root 7459 7167 0 Aug28 ? 00:09:13 /usr/bin/dummy
erv 23720 17254 0 13:22 pts/4 00:00:00 grep dummy
sh-3.2$
As #nos has already said, pstree displays threads by default, but ps -ef does not.
ps can show threads, you just didn't ask it to. Try this (it might depend what version you have):
ps -eLf
This is all in the man page.
Linux threads are merely processes that share the same address space as another process. It's like a fork that didn't break away cleanly. You can read more in the clone syscall documentation.
I'm a bit confused when a multiple su happen. Lets say a situation like this happen:
Fikrie su to root :
ps -ef | grep su:
root 15524 15388 0 10:15 pts/0 00:00:00 su root
I know that the pid for that su is 15524 and the parent pid is 15388. But when a multiple su happen. eg : this situation.
Fikrie su root:
root su fikrie2:
fikrie 2 su root:
ps -ef | grep su:
root 15450 15388 0 10:15 pts/0 00:00:00 su root
fikrie2 15468 15458 0 10:15 pts/0 00:00:00 su fikrie2
root 15478 15476 0 10:15 pts/0 00:00:00 su root
I thought that when root su into fikrie2, the first pid will be the ppid for the second su. Somehow when I tried to grep the process, this confuses me. The ppid became 15458 instead of 15450 or 15388. None of the ppid are connected/related to the ppid or pid before it. I tried to google and read about process relationship in Advanced Programming in the UNIX Environment book. Can someone give me a good explanation about this or maybe a link to help me understand more on the process relationship.
I'm trying to write a code to find the user that su into that user. From all the answer I look into SO, they only help to find the original user, eg. fikrie. If the second situation happen, I wasn't able to get fikrie2 when I su to root from fikrie2. Instead I get fikrie which is the original user. My original idea was to use the parent id to get the user, but when doing it from command line. This really confuse me.
PS* I'm trying this on Unix platform. I do not know anything about Windows, but if the ppid and pid are different between Windows and Unix, please point me the direction into Unix.
I'm not sure, but I suspect that the parent process that you are seeing is the shell which got called. When you su you will run the .profile which will call multiple other processes and will end with a shell being launched. So the parent process isn't going to be the previous invocation of su, because that isn't the process which spawned this one. The shell did that.
I wrote a small C utility called killSPR to kill the following processes on my RHEL box. The idea is for anyone who logs into this linux box to be able to use this utility to kill the below mentioned processes (which doesn't work - explained below).
cadmn#rhel /tmp > ps -eaf | grep -v grep | grep " SPR "
cadmn 5822 5821 99 17:19 ? 00:33:13 SPR 4 cadmn
cadmn 10466 10465 99 17:25 ? 00:26:34 SPR 4 cadmn
cadmn 13431 13430 99 17:32 ? 00:19:55 SPR 4 cadmn
cadmn 17320 17319 99 17:39 ? 00:13:04 SPR 4 cadmn
cadmn 20589 20588 99 16:50 ? 01:01:30 SPR 4 cadmn
cadmn 22084 22083 99 17:45 ? 00:06:34 SPR 4 cadmn
cadmn#rhel /tmp >
This utility is owned by the user cadmn (under which these processes run) and has the setuid flag set on it (shown below).
cadmn#rhel /tmp > ls -l killSPR
-rwsr-xr-x 1 cadmn cusers 9925 Dec 17 17:51 killSPR
cadmn#rhel /tmp >
The C code is given below:
/*
* Program Name: killSPR.c
* Description: A simple program that kills all SPR processes that
* run as user cadmn
*/
#include <stdio.h>
int main()
{
char *input;
printf("Before you proceed, find out under which ID I'm running. Hit enter when you are done...");
fgets(input, 2, stdin);
const char *killCmd = "kill -9 $(ps -eaf | grep -v grep | grep \" SPR \" | awk '{print $2}')";
system(killCmd);
return 0;
}
A user (pmn) different from cadmn tries to kill the above-mentioned processes with this utility and fails (shown below):
pmn#rhel /tmp > ./killSPR
Before you proceed, find out under which ID I'm running. Hit enter when you are done...
sh: line 0: kill: (5822) - Operation not permitted
sh: line 0: kill: (10466) - Operation not permitted
sh: line 0: kill: (13431) - Operation not permitted
sh: line 0: kill: (17320) - Operation not permitted
sh: line 0: kill: (20589) - Operation not permitted
sh: line 0: kill: (22084) - Operation not permitted
pmn#rhel /tmp >
While the user waits to hit enter above, the process killSPR is inspected and is seen to be running as the user cadmn (shown below) despite which killSPR is unable to terminate the processes.
cadmn#rhel /tmp > ps -eaf | grep -v grep | grep killSPR
cadmn 24851 22918 0 17:51 pts/36 00:00:00 ./killSPR
cadmn#rhel /tmp >
BTW, none of the main partitions have any nosuid on them
pmn#rhel /tmp > mount | grep nosuid
pmn#rhel /tmp >
The setuid flag on the executable doesn't seem to have the desired effect. What am I missing here? Have I misunderstood how setuid works?
First and foremost, setuid bit simply allows a script to set the uid. The script still needs to call setuid() or setreuid() to run in the the real uid or effective uid respectively. Without calling setuid() or setreuid(), the script will still run as the user who invoked the script.
Avoid system and exec as they drop privileges for security reason. You can use kill() to kill the processes.
Check These out.
http://linux.die.net/man/2/setuid
http://man7.org/linux/man-pages/man2/setreuid.2.html
http://man7.org/linux/man-pages/man2/kill.2.html
You should replace your system call with exec call. Manual for system say's it drops privileges when run from suid program.
The reason is explained in man system:
Do not use system() from a program with set-user-ID or set-group-ID
privileges, because strange values for some environment variables might
be used to subvert system integrity. Use the exec(3) family of func‐
tions instead, but not execlp(3) or execvp(3). system() will not, in
fact, work properly from programs with set-user-ID or set-group-ID
privileges on systems on which /bin/sh is bash version 2, since bash 2
drops privileges on startup. (Debian uses a modified bash which does
not do this when invoked as sh.)
If you replace system with exec you will need to be able to use shell syntax unless you call /bin/sh -c <shell command>, this is what is system actually doing.
Check out this link on making a shell script a daemon:
Best way to make a shell script daemon?
You might also want to google some 'linux script to service', I found a couple of links on this subject.
The idea is that you wrap a shell script that has some basic stuff in it that allows a user to control a program run as another user by calling a 'service' type script instead. For example, you could wrap up /usr/var/myservice/SPRkiller as a 'service' script that could then just be called as such from any user: service SPRkiller start, then SPRkiller would run, kill the appropriate services (assuming the SPR 'program' is run as a non-root user).
This is what it sounds like you are trying to achieve. Running a program (shell script/C program/whatever) carries the same user restrictions on it no matter what (except for escalation bugs/hacks).
On a side note, you seem to have a slight misunderstanding of user rights on Linux/Unix as well as what certain commands and functions do. If a user does not have permissions to do a certain action (like kill the process of another user), then calling setuid on the program you want to kill (or on kill itself) will have no effect because the user does not have permission to another users 'space' without super user rights. So even if you're in a shell script or a C program and called the same system command, you will get the same effect.
http://www.linux.com/learn/ is a great resource, and here's a link for file permissions
hope that helps
Does there is usual utility which makes a substitution on some calls like execve and open? Like LD_PRELOAD for calls.
Example:
we have prog_A which uses prog_B.
some days ago prog_B was updated and now prog_A failed!(
usual solution is the next:
$: mv /usr/bin/prog_b /usr/bin/prog_B.new
$: ln -s /usr/bin/prog_b.old /usr/bin/prog_b
$: ./prog_a # now run
but sometimes it's uncomfortably and dirty solution. In some stories the correct way to do so:
$: util "execve+open+stat:/usr/bin/prog_b=/usr/bin/prog_b.old" ./prog_a
where execve,open & stat are system calls. What is the name of this util?
I just write a special FILE_PRELOAD utility to solve my problem.
$: FILE_PRELOAD -C "execve+open+stat:/usr/bin/prog_b:/usr/bin/prog_b.old" ./prog_a
it generates c++ code, then compiles it and then LD_PRELOAD the result lib.so file before run ./prog_a.
Using it you can hook the next calls:
open,fopen,fopen64
opendir,mkdir,rmdir
execve
unlink,unlinkat
stat,lstat,lstat64,_lxstat,_lxstat64,stat64
_xstat,_xstat64,__fxstatat
freopen,freopen64
Please, run docs/tut.sh firstly (it's a tutorial for FP utility).
The common solution is the symlink solution. It isn't dirty. Have a look at debian or Ubuntu for example. They have /etc/alternatives for that purpose.
Here comes an example listing for the view command on Ubuntu:
user#server ls -al /usr/bin/view
lrwxrwxrwx 1 root root 22 Dez 5 2009 /usr/bin/view -> /etc/alternatives/view
user#server ls -al /etc/alternatives/view
lrwxrwxrwx 1 root root 18 Dez 5 2009 /etc/alternatives/view -> /usr/bin/vim.basic