5 Reasons Why Ubuntu Is More Secure Than Windows & Mac OS X

1. Linux Has Limited Default User Privileges

In Windows OS/Mac OS users get the authentication to access everything on the system as, by default, they are given administrator privileges. When viruses make their way to the system, they can easily spread and invest the rest of the system. Here is why Linux is great. On Linux the users are given lower access and hence virus can only reach to the local files and folders so the system wide damage is saved.

What that means is that even if a Linux system is compromised, the virus won’t have the root access it would need to do damage system wide; more likely, just the user’s local files and programs would be affected. That can make the difference between a minor annoyance and a major catastrophe in any business setting.

2. Linux Has Tougher Program Permissions

This sort of goes along with Linux Privileges but there is a difference. In a Mac OS or Window OS machine, if a user downloads an email with an attachment that has a virus, all the user has to do is run the file and the file can infect the system but on Linux and even Chrome OS, that’s not possible. Linux/Ubuntu would require the user to actually give the program even more permissions before it gets a chance to install anything on your machine, brilliant coding. I do hear that starting from Windows 10, Windows OS will try to follow a similar setup.

3. Linux Has A Powerful Auditing System

Linux/Ubuntu has awesome Auditing system by default. Including detailed Logs that can tell you exactly what a user/program attempted to do. Basically an internal key logger that monitors everything including failed login attempts.

4. Linux Is Open Source

This matters much more than people think. Because Linux is an open source operating system, whenever a virus or a huge bug goes public, millions of people from all over the world try their best to help patch it up. Once a user finds a way to fix the issue they can send their updated code directly to the official Linux employees and they can add it to the next update. This system works well unlike Windows OS/Mac OS X where only a few paid employees have direct access to the code hence it usually takes longer for Windows and Mac systems to fix a bug or secure an exploit. Lets hope Linux stays open source forever!

5. Linux Has Less Users That Use It

Whether we Linux people like to admit or not, not many people use Linux! Yes we know it is used by almost every web hosting company/company organization to store data etc but when it comes to the regular user, your neighbor, your girlfriend/boyfriend or your grandma, most of them will choose Windows over any other OS and this is a good thing because it means less viruses/spyware will be designed for Linux. The less popular you are, the more people ignore you, get it? Lol it’s really as simple as that.

Let me just remind you all that even though Linux/Ubuntu might be the most secure OS in the market, it doesn’t mean it is 100% hacker proof. Hell, there are a few viruses on the Linux system that’s why you still need some anti-virus apps for Ubuntu installed on your system to be safe no matter what.

source:http://www.ubuntufree.com/

25 Linux commands for System Administrators

man

The most important command in Linux, man shows information about other commands. You can start by running “man man” to find more about the man command.

uptime

This command tells you how long your system has been running for.

w

This command shows who is logged into your system and what they are currently doing.

users

This shows you the usernames of users who are currently logged in to your system.

whoami

Prints the username of the user that you are currently logged in as.

grep

Finds text in files and outputs the neighbouring text along with file names. You can recursively search in multiple files using -r. You can output only file names using -l.

less

If the case your output of a command or file contests are more your screen can accomodate, you can view it in parts using less. The output of the previous command using less is the following.

cat

This helps in displaying, copying or combining text files.

pwd

Prints the absolute path of the current working directory.

ssh

This commands helps you connect to a remote host. You can either connect as

   ssh remote_host

or

   ssh remote_username@remote_host

scp

Copy files securely and remotely over servers.

sudo

Use this to run any command as the superuser (root). It is prefixed to the commands.

service

You can use it to perform tasks on different services, which runs scripts for the corresponding services. For instance, to restart apache2 web server, we use service apache2 restart. A sudo is prefixed to run as root because all users do not have permission to run the scripts.

Do note that some do not require sudo.

locate

Find files on your system by name.

chmod

Chmod changes file permissions in Linux. You can set which users or user groups have what kind of access to a particular file. The topic of file permissions in Linux is a huge one in itself and beyond the scope of this post. You can, however, look at this thread for further reading.

chown

Change ownership of a file to a user or a user group.

pkill

Kill a process using this command.

crontab

This is a program that is used to manage cron jobs in Linux. To list existing cron jobs, run crontab -l.

alias

You use an alias when you are in need to shorten a command.

Aliases are not saved after you close the current terminal session. To do that you need to create an alias in ~/.bashrc.

echo

Display or output text. Used in making bash scripts.

cmp

This command compares two files byte by byte.

mount

Mounts a filesystem. There are different options in this command that you can use which enables you to mount even remote file systems.

pmap

This command is used to show the memory map of a process. You can get the process id (pid) by running

   ps aux | grep <process_name>

Then run pmap -x <pid>

wget

Downloads a file from a network.

ifconfig

This command is used to configure a network’s interface. Just writing the command displays the configuration.

With this, we come to the end of the list of the important commands. We hope that it was educational for you. If you have any issues, feel free to comment below!

Apache on CentOS Linux For Beginners

Install Apache in the usual way with Yum, set it to automatically start at boot, and then start it:

$ sudo yum -y install httpd
$ sudo systemctl enable httpd.service
$ sudo systemctl start httpd.service

Point a web browser to http://localhost, and you should see a test page (Figure 1).

apache-test-page.png

Figure 1: Apache test page.

Used with permission

It works! We are wonderful.

SELinux

CentOS installs with an active SELinux configuration set to SELINUX=enforcing in /etc/sysconfig/selinux, which will prevent your new virtual hosts from operating. There are two ways to handle this. One way is to disable SELinux by changing SELINUX=enforcing to SELINUX=permissive, and then rebooting. This keeps your rules active without enforcing them, and logs all SELinux messages so you can study how the rules are working, and if they are set correctly.

The other way is to leave SELinux in enforcing mode and create a ruleset for your new virtual host. In the following examples our virtual host root is /var/www/html/mysite.com:

$ sudo semanage fcontext -a -t httpd_sys_rw_content_t \
  '/var/www/html/mysite.com(/.*)?'
restorecon -RF /var/www/html/mysite.com

While you're testing and learning, you could make this ruleset apply to your entire web root by using '/var/www/html(/.*)?' instead of creating rules for each individual virtual host. Note that neither of these rulesets are very secure; they're for making testing easier. A more secure SELinux configuration is more fine-grained and applied to individual directories; I leave it as your homework to study how to do this.

Configuration Files

CentOS/etc. use a different configuration file structure than the Debian Linux family. Apache configuration files are stored in /etc/httpd. The default CentOS 7 installation supplies these directories:

conf
conf.d
conf.modules.d
logs
modules
run

conf contains the main server configuration file, httpd.conf. You probably won't edit this file very often. This contains global configurations such as the location of the configuration files, include files, the Apache user and group, document root, and log file location and format.

conf.d is where your virtual hosts and any other custom configurations go. It contains welcome.conf, which is is the default virtual host that displays the default welcome page. autoindex.conf enables directory listings, and php.conf controls how Apache interacts with PHP.

All files in conf.d must have a .conf extension. This is controlled in httpd.conf, so you have the option to change it to whatever you want. Really. Even something goofy, like .feedme or .hiapache.

conf.modules.d loads whatever installed modules you want to use.

logs, modules, and run are all symlinks to other directories. Take a little time to study your configuration files and see what is in them.

Create a new virtual host

Now that we have an inkling of what to do, let's create a new virtual host and its welcome page. In this example it is mysite.com.

$ sudo mkdir -p /var/www/html/mysite.com
$ cd /var/www/html/test.com
$ sudo nano index.html

You are welcome to copy this fabulous custom welcome page:

<head>
<title>Mysite.com index page</title>
</head>
<h1>Hello, welcome to mysite.com! It works!</h1>            
<h2>That is all I have to say. If you don't 
see this then it doesn't work.</h2>
</body>
</html>

Test your new index page by opening it in a web browser (Figure 2), which in this example is file:///var/www/html/mysite.com/index.html.

mysite-test-page.png

Figure 2: Mysite test page.

Used with permission

Excellent, the welcome page renders correctly. Now let's configure a virtual host to serve it up, /etc/httpd/conf.d/mysite.conf.

$ cd /etc/httpd/conf.d/
$ sudo nano mysite.conf

This is a basic barebones virtual host:

<VirtualHost *:80>
    ServerAdmin carla@localhost
    DocumentRoot /var/www/html/mysite.com
    ServerName mysite.com
    ServerAlias mysite.com
</VirtualHost>

Now point a web browser to http://localhost/mysite.com to (Figure 3).

mysite-test-page-2.png

Figure 3: Mysite virtual host.

Used with permission

Behold! Your fab new virtual host lives! If it doesn't look right restart Apache, and force your browser to bypass its cache by pressing Shift+reload. After years of testing multiple setups and running Apache on all kinds of Linux distributions, I'm rather muddled on when you need to restart or reload the configuration without restarting, or when Apache picks up new configurations automatically. During your testing, you can restart it with gay abandon.

Multiple virtual hosts

For quick easy testing map your server's IP address to your domain names in /etc/hosts:

192.168.1.25       mysite.com
192.168.1.25       www.mysite.com

Now you can access http://mysite.com and http://www.mysite.com without the localhost portion of the address. Copy these /etc/hosts entries to other hosts on your LAN, and they should also have access to your site.

To set up more sites repeat these steps, creating different document roots and domains for each one, and their corresponding entries in /etc/hosts. For example, adding second virtual host looks like this:

192.168.1.25       mysite.com
192.168.1.25       www.mysite.com
192.168.1.25       mycatpics.com
192.168.1.25       www.mycatpics.com

And beware of SELinux.

When you're ready to roll out a production server refer to Dnsmasq For Easy LAN Name Services to learn how to set up DNS on your LAN with the excellent Dnsmasq name server.

Creating a publicly accessible Internet web server is a much bigger job that involves registering domain names, setting up careful and correct DNS, and building a good firewall. Do please study this with great care.

The fine Apache documentation is exhaustively thorough, and it makes more sense when you have a live server running, and have some idea of how things work

source: linux.com.

How To Install Proprietary Graphics Drivers In Ubuntu & Fedora [Linux]

Being a Linux user lets you have a pretty cool choice – open source or proprietary software. While a lot of die-hard Linux users will scream at you if you use anything proprietary (and I recommend not using proprietary software unless absolutely necessary, but that’s still your choice), you can still install whatever the heck you want.

There are a good amount of proprietary products that are being made available for Linux, both free and paid, and they aren’t going away anytime soon. But because Linux allows the best of both worlds, you may also be curious about the proprietary drivers that are available.

Why Do You Possibly Need Proprietary Drivers?

In virtually all distributions, only open source drivers that come with the Linux kernel are used out of the box. While this should be perfectly fine for simple use (and it should work on any graphics setup), AMD and nVidia users may still feel the need to use the more powerful proprietary drivers so that games, videos, and more all play as smoothly as possible.

Intel users shouldn’t feel left out. Intel doesn’t offer any proprietary drivers, but instead pushes all of its work directly to its only set of graphics drivers, which are open source and included with the kernel.

Ubuntu

Ubuntu users have the easier route to getting these drivers installed. You’ll simply need to open your dash, menu, etc. and look for the Additional Drivers application. This little program will look to see if you have any hardware in your system that could be better supported through proprietary drivers. While it may also include wireless drivers, this is usually the place for the proprietary graphics drivers.

Simply click on which you’d like to install (I’d usually go with the latest), and apply.

If you like a more technical route, you can technically find the fglrx package for AMD cards and nvidia-glx-xxx for nVidia cards (where xxx is the version number, like 185), but I recommend using the Additional Drivers application as it takes care of everything, and I’ve run into problems just installing fglrx through the package manager instead of through Additional Drivers.

Fedora

Fedora users have it a little more difficult, but it’s very manageable. First, you’ll need to head over to this site and install the free and non-free packages for your version of Fedora. These packages will add information about the repository which hosts the proprietary drivers, as the default repositories of Fedora are open-source only. Once that completes, you should now be able to search for kmod-catalyst for AMD cards or kmod-nvidia for nVidia cards.

This is a package that keeps track of dependencies and kernel modules, so whenever you install a new kernel it’ll update the drivers as well. Install, restart, and you’re up and running!
source: makeuseof.com

The Reasons Why We Use Linux Kill Signals And Commands

Kill Commands
The kill commands (such as kill, xkill, etc.) are commands that use the the "kill()" system call. In other words, the command-line kill commands are wrappers for the kernel's "kill()" syscall.

kill
The kill command will kill a process using the kill signal and PID given by the user. To use the SIGKILL signal with "kill", type one of the following for a process with a PID of 1710.

Code:

kill -9 1710
kill -SIGKILL 1710
kill -KILL 1710

The kill command accepts either the signal number, partial name (omitting “SIG”) or name (signals have both a number and name that can be referenced). The name must be in all caps. However, some systems do not support partial names.

killall
The killall command kills all process with a particular name. For instance, Nautilus may be running several times. To kill all of them type "killall -SIGQUIT nautilus". Also, if Firefox is running once and the user does not know the PID, use the killall command - "killall -9 firefox". The killall command also uses case-sensitive kill signals (they are all uppercase). Below demonstrates what will happen when the kill signal is typed in lowercase. Notice that the command uses the "s" as a parameter and then it does not know what to do with the rest of the information. It then tries to use "igkill" as a kill signal, but no such signal exists.

Code:

collier@Nacho-Laptop:~$ killall -sigkill nautilus
igkill: unknown signal; killall -l lists signals.

pkill
This command is a lot like killall except it allows partial names. So, "pkill -9 unity" will kill any process whose name begins with "unity". pkill can also kill all processes owned by a particular user - “pkill -9 -u USERNAME”

xkill
This command allows users to kill a command by clicking the window. This kill command is offered by the X Server and is only usable on systems using X11. In a terminal, type "xkill" and then the cursor will change. Next, click a window to kill. The application should disappear and leave the system's memory. Then, the cursor will return to normal. Alternate display servers (like Weston and Mir) do not support xkill and do not have equivalents (at this time).

Signals
There are many kill signals that each serve a particular purpose. Typing "kill -l" will list the kill signals supported by that particular utility (explained in a moment). Notice that all kill signals begin with "SIG"; this means SIGnal.

Code:

kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE
9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2
13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO
30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1
36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5
40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9
44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13
52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9
56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5
60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1
64) SIGRTMAX

Yes, certain numbers are missing because those signals are not supported on my system or by that kill command, or they were discontinued. If you run the same command, you may have different numbers missing/available.

Here is a typically unknown trick. Many shells (such as BASH) have their own kill command that is separate from the system's kill command (/bin/kill). To see this on a system, type "kill -l", "kill -L", "/bin/kill -l", and "/bin/kill -L" in a terminal one at a time. It can be seen that the results are different between kill and /bin/kill. There are some signals and parameters supported by one and not the other. However, everyone has SIGHUP (1), SIGQUIT (3), SIGKILL (9), and SIGTERM (15). Those are the most common and useful signals. It is important to learn and memorize those four very well when administering Linux systems.

 

Kill signals are not only used to close locked-up applications, but also stop software from performing unallowed tasks. This means some of these kill signals are part of security. Surprisingly, kill commands not only stop/kill processes but they also pause, continue, and restart processes.

A list of signals supported by the kernel can be found in /usr/include/linux/signal.h. This file may show that the signals come from two assembly libraries (/usr/include/asm/signal.h and /usr/include/asm/siginfo.h).

Signal Descriptions
NOTE: This is alphabetically sorted.

• SIGABRT - This kill signal is the abort signal. Typically, a process will initiate this kill signal on itself.
• SIGALRM - SIGALRM is sent when the real-time or clock-time timer expires.
• SIGBUS - When a process is sent the SIGBUS signal, it is because the process caused a bus error. Commonly, these bus errors are due to a process trying to use fake physical addresses or the process has its memory alignment set incorrectly.
• SIGCHLD - When a parent process loses its child process, the parent process is sent the SIGCHLD signal. This cleans up resources used by the child process. In computers, a child process is a process started by another process know as a parent.
• SIGCONT - To make processes continue executing after being paused by the SIGTSTP or SIGSTOP signal, send the SIGCONT signal to the paused process. This is the CONTinue SIGnal. This signal is beneficial to Unix job control (executing background tasks).
• SIGEMT - Processes receive this signal when an emulator trap occurs.
• SIGFPE - Processes that divide by zero are killed using SIGFPE. Imagine if humans got the death penalty for such math. NOTE: The author of this article was recently taken out to the street and shot for dividing by zero. (^u^)
• SIGHUP - The SIGHUP signal disconnects a process from the parent process. This an also be used to restart processes. For example, "killall -SIGHUP compiz" will restart Compiz. This is useful for daemons with memory leaks.
• SIGILL - When a process performs a faulty, forbidden, or unknown function, the system sends the SIGILL signal to the process. This is the “ILLegal SIGnal”.
• SIGINFO - Terminals may sometimes send status requests to processes. When this happens, processes will also receive this signal.
• SIGINT - This signal is the same as pressing ctrl-c. On some systems, "delete" + "break" sends the same signal to the process. The process is interrupted and stopped. However, the process can ignore this signal.
• SIGIO - An alias to SIGPOLL.
• SIGIOT - This is an alias for SIGABRT.
• SIGKILL - The SIGKILL signal forces the process to stop executing immediately. The program cannot ignore this signal. This process does not get to clean-up either.
• SIGLOST - Processes trying to access locked files will get this signal. Many systems use SIGLOST as an alias for SIGPOLL especially since accessing locked files is an asynchronous I/O event.
• SIGPIPE - When a process tries to write to a pipe that lacks an end connected to a reader, this signal is sent to the process. A reader is a process that reads data at the end of a pipe.
• SIGPOLL - When a process causes an asynchronous I/O event, that process is sent the SIGPOLL signal. SIGPOLL and SIGIO are aliases. In the assembly source code, SIGIO is defined as "29" and SIGPOLL is defined as "SIGIO".
• SIGPROF - SIGPROF is sent when CPU time used by the process and by the system on behalf of the process elapses.
• SIGPWR - Power failures will cause the system to send this signal to processes (if the system is still on).
• SIGQUIT - This is like SIGINT with the ability to make the process produce a core dump.
• SIGRTMAX* - This is a set of signals that varies between systems. They are labeled SIGRTMAX-1, SIGRTMAX-2, SIGRTMAX-3, ......., and so on (usually up to 14). These are user-defined signals; they must be programmed in the Linux kernel's source code. That would require the user to know C/C++.
• SIGRTMIN* - This is a set of signals that varies between systems. They are labeled SIGRTMIN+1, SIGRTMIN+2, SIGRTMIN+3, ......., and so on (usually up to 15). These are user-defined signals; they must be programmed in the Linux kernel's source code. That would require the user to know C/C++.
• SIGSEGV - When an application has a segmentation violation, this signal is sent to the process.
• SIGSTOP - This signal makes the operating system pause a process's execution. The process cannot ignore the signal.
• SIGSYS - Processes that give a system call an invalid parameter will receive this signal.
• SIGTERM - This signal requests a process to stop running. This signal can be ignored. The process is given time to gracefully shutdown. When a program gracefully shuts down, that means it is given time to save its progress and release resources. In other words, it is not forced to stop. SIGINT is very similar to SIGTERM.
• SIGTRAP - This signal is used for debugging purposes. When a process has performed an action or a condition is met that a debugger is waiting for, this signal will be sent to the process.
• SIGTSTP - This signal is like pressing ctrl-z. This makes a request to the terminal containing the process to ask the process to stop temporarily. The process can ignore the request.
• SIGTTIN - When a process attempts to read from a tty (computer terminal), the process receives this signal.
• SIGTTOU - When a process attempts to write from a tty (computer terminal), the process receives this signal.
• SIGUNUSED - On many systems, this is an alias for SIGSYS.
• SIGURG - When a process has urgent data to be read or the data is very large, the SIGURG signal is sent to the process.
• SIGUSR1 - This indicates a user-defined condition. This signal can be set by the user by programming the commands in sigusr1.c. This requires the programmer to know C/C++.
• SIGUSR2 - This indicates a user-defined condition.
• SIGVTALRM - SIGVTALRM is sent when CPU time used by the process elapses.
• SIGWINCH - When a process is in a terminal that changes its size, the process receives this signal.
• SIGXCPU - When a process uses the CPU past the allotted time, the system sends the process this signal. SIGXCPU acts like a warning; the process has time to save the progress (if possible) and close before the system kills the process with SIGKILL.
• SIGXFSZ - Filesystems have a limit to how large a file can be made. When a program tries to violate this limit, the system will send that process the SIGXFSZ signal.

Signals Defined in /usr/include/asm/signal.h (Linux 3.19.0-21-generic)

Code:

#define SIGHUP  1
#define SIGINT  2
#define SIGQUIT  3
#define SIGILL  4
#define SIGTRAP  5
#define SIGABRT  6
#define SIGIOT  6
#define SIGBUS  7
#define SIGFPE  8
#define SIGKILL  9
#define SIGUSR1  10
#define SIGSEGV  11
#define SIGUSR2  12
#define SIGPIPE  13
#define SIGALRM  14
#define SIGTERM  15
#define SIGSTKFLT  16
#define SIGCHLD  17
#define SIGCONT  18
#define SIGSTOP  19
#define SIGTSTP  20
#define SIGTTIN  21
#define SIGTTOU  22
#define SIGURG  23
#define SIGXCPU  24
#define SIGXFSZ  25
#define SIGVTALRM  26
#define SIGPROF  27
#define SIGWINCH  28
#define SIGIO  29
#define SIGPOLL  SIGIO
/*#define SIGLOST  29*/
#define SIGPWR  30
#define SIGSYS  31
#define SIGUNUSED  31

Users can use these kill signals using one of the many kill commands, such as pkill, xkill, etc. (if supported). When sending a signal to a process owned by another user (like Root), the user needs admin privileges and must use the sudo command. Be careful though, misuse of these signals can cause system damage. For instance, using SIGTERM on a GUI process like Compiz, X11, XFCE, Unity, Gnome-shell, etc. will make the system unviewable. However, some GUI processes will turn back on.

NOTE: If Compiz or some other important GUI utility freezes, crashes, etc., use SIGHUP to restart the GUI.

The Zero Signal
There is another signal that is supported by most systems, but is not list in the "kill -l" command. This is the "0" signal which is called "SIGT". This signal is used to see if the user can send signals to the specified PID/process. For instance, if a user owns a process and the process is running, then the command "kill -0 PID" will return "0". However, if the user does not own the specified PID or the PID is not assigned to a process, then the return value is "1".

Not all systems and kill commands support "0" or support it properly. For instance, on Ubuntu 15.04 (Vivid Vervet), the signal "0" and "SIGT" do not work with the "kill" command supplied by Bash or "/bin/kill".

Code:

collier@Nacho-Linux:~$ pidof firefox
21609
collier@Nacho-Linux:~$ /bin/kill 0 21609
Terminated
collier@Nacho-Linux:~$ /bin/kill SIGT 21609
kill: failed to parse argument: 'SIGT'
collier@Nacho-Linux:~$ kill 0 21609 # This killed Firefox
collier@Nacho-Linux:~$ pidof firefox
collier@Nacho-Linux:~$

Getting a Process's PID
To get the PID of a process (assuming the process name is known), try the below commands.

• pidof PROCESS_NAME
• ps aux | grep PROCESS_NAME
• kill -p PROCESS_NAME
• kill --pid PROCESS_NAME

NOTE: Not all systems and kill commands support "kill -p" or "kill --pid".

When combining a PID-finding command with the kill command, a user could type something like

Code:

kill -TERM `pidof geany`

Kill PID 0 and Negative PIDs
If the kill command is used and a PID of zero "0" is specified, then all processes with the same Group ID (GID) of the sender will be affected by the kill signal.

If the specified PID is negative one (-1) and the user is not using Root-privileges, then all of the processes with the same User ID (UID) as the sending user are killed. However, if the sender is Root or using Root-privileges, then all processes except system processes, processes with a Process Group ID (PGID) of 1, and the sending process are killed.

The System V standard specifies that negative PIDs more negative (smaller) than one (i.e. -2, -3, -4, ...) will act like PID -1, but in addition, kill only those processes with a process Group ID equal to the absolute value of the negative PID. This means PID -2 will affect processes with a Process Group ID (PGID) of 2 (since |-2| = 2 or abs(-2) = 2).


source:http://www.linux.org/