Set user ID, set group ID, sticky bit

Source taken from: http://wiki.e107.org/?title=Unix_Permissions

In addition to the basic UNIX permissions, there are also three bits of information defined for files in UNIX:

• SUID or setuid: change user ID on execution. If setuid bit is set, when the file will be executed by a user, the process will have the same rights as the owner of the file being executed.
• SGID or setgid: change group ID on execution. Same as above, but inherits rights of the group of the owner of the file. For directories it also may mean that when a new file is created in the directory it
• Sticky bit. It was used to trigger process to "stick" in memory after it is finished, now this usage is obsolete. Currently its use is system dependant and it is mostly used to suppress deletion of the files that belong to other users in the folder where you have "write" access to.

Numeric representation

Octal digit Binary value Meaning

• 0 000 setuid, setgid, sticky bits are cleared
• 1 001 sticky bit is set
• 2 010 setgid bit is set
• 3 011 setgid and sticky bits are set
• 4 100 setuid bit is set
• 5 101 setuid and sticky bits are set
• 6 110 setuid and setgid bits are set
• 7 111 setuid, setgid, sticky bits are set

Textual representation

SUID

• If set, then replaces "x" in the owner permissions to "s", if owner has execute permissions, or to "S" otherwise. Examples:
• -rws------ both owner execute and SUID are set
• -r-S------ SUID is set, but owner execute is not set

SGID

• If set, then replaces "x" in the group permissions to "s", if group has execute permissions, or to "S" otherwise. Examples:
• -rwxrws--- both group execute and SGID are set
• -rwxr-S--- SGID is set, but group execute is not set

Sticky

• If set, then replaces "x" in the others permissions to "t", if others have execute permissions, or to "T" otherwise. Examples:
• -rwxrwxrwt both others execute and sticky bit are set
• -rwxrwxr-T sticky bit is set, but others execute is not set

What are the SUID, SGID and the Sticky Bits?

Source taken from http://www.codecoffee.com/tipsforlinux/articles/028.html

Linux has some special attributes associated with all files. Often in X Windows when you check the properties of any file (by right clicking on it and viewing its properties) you would get to see 3 special attributes besides the common read/write/execute rights for the owner/group/others. The 3 extra attributes are known as SUID, SGID and Sticky Bits

Sticky Bit

Lets start with Sticky bit first. Since this is the most simplest to explain. Setting the sticky bit tells Unix that once the concerned application is executed, it should remain in memory. Remember that Unix is a multi-user OS and was mainly designed so that multiple users can work simultaneously. Thus the logic used is that a program that exists in memory requires lesser time to start when a new user requests for the same program. Thus when one user has just used a program and then a new user wants to use the same program, the second user doesn't have to face a time delay for the program to initialize itself. It would be readily available to him. The concept of the sticky bit was a very useful one, long back when fast disk access and other memory access technologies weren't around. But in today's age the concept of sticky bit is obsolete, since modern day technology is advanced enough to reduce the time delay while loading applications into the memory. Thus currently the sticky bit is of very little significance. Sticky bit is only associated with executables.

SUID (Set User ID) Bit

Sometime you may faced an error while trying to run any application stating that the application must be 'SUID root' . You might have been confused that time, but now once you read this article you would no longer find it confusing.

SUID stands for Set User ID. This means that if the SUID bit is set for any application then your user ID would be set as that of the owner of application/file rather than the current user, while running that application. That means in case I have an application whose owner is ' root ' and it has its SUID bit set, then when I run this application as a normal user, that application would still run as root. Since the SUID bit tells Linux that the the User ID root is set for this application and whenever this application executes it must execute as if root was executing it (since root owns this file).

In case you have really understood the above you may be wondering - isnt this a major security risk? If users are able to run applications as root, then it must be definitely posing as a threat to the security of the system. Actually the SUID is used to increase the security in a way. Let me explain this with my own example I use on my machine.


One way I use SUID on my machine

I have a few files that I modify through Linux and then before I shutdown Linux I have to transfer them to my Windows partition for further use there. As a normal user I do not have write access to the Windows partitions that I have mounted. So I have to be the superuser to be able to write to that partition. I have created a simple shell script that copies my files to the Windows partitions. This script was created by root user and the SUID bit was set. Access rights to this script have been given to all users. Now whenever I want to copy my files I simply run this script. Even though I have logged in as a normal user, the SUID bit which is set causes this script to execute as if the root was executing it and it allows me to write to the Windows partitions.

Had the SUID bit not been set, I would have to type ' su ' at the prompt and get temporary superuser access to get write access to the Windows partitions. Hope you got the point..

You may be thinking that since these applications would run as root they can do harmful things and destroy the system. The concept behind SUID bit is that you as the superuser would be able to allow certain applications / scripts to be run by the users as if they were the superuser for the time being. What these application / scripts do when they execute should be completely known to you. Even though the users would be allowed to execute these programs as root they would be able to do ONLY THOSE things that these programs were designed to do. So in case a script was designed to copy 5 files from one place to another. Then the user who would run that script would be able to ONLY copy those 5 files from one place to another. He would not be able to modify that script in any way since he would not have write access to the script. He would only be having execute rights for that script. Hence its an excellent idea to allow users to do some important backup using a script that does only that and by setting the SUID bit for that script. This way the users don't have to know the superuser password but can still use some facilities that are only available to the superuser

Important : Think twice before setting the SUID bit for scripts (owned by root) that take arguments at the command line. Since you never know what parameters a malicious user may pass to your script. Since the script would run as root it could do great damage if misused.


SGID (Set Group ID) bit

Just like SUID, setting the SGID bit for a file sets your group ID to the file's group while the file is executing. IT is really useful in case you have a real multi-user setup where users access each others files. As a single homeuser I haven't really found a lot of use for SGID. But the basic concept is the same as the SUID, the files whose SGID bit are set would be used as if they belong to that group rather than to that user alone.

Note : Making SUID and SGID programs completely safe is very difficult (or maybe impossible) thus in case you are a system administrator it is best to consult some professionals before giving access rights to root owned applications by setting the SUID bit. As a home user (where you are both the normal user and the superuser) the SUID bit helps you do a lot of things easily without having to log in as the superuser every now and then.

HACMP health-check command

To check RG availability on HACMP server, execute the command as below:

# /usr/es/sbin/cluster/utilities/clRGinfo

To check setting of the HACMP cluster:

# /usr/es/sbin/cluster/utilities/cltopinfo

To check the current status of the cluster:

# /usr/es/sbin/cluster/utilities/clstat

How to collect system info for IBM to investigate (snap command)

Below is the general step how to collect system info for IBM to investigate:

1. run snap -r (answer yes if asked).
2. run snap -ac (additional option '-e' to collect HAMCP cluster information)
3. rename the file in step 2. under /tmp/ibmsupt directory to the name that has been specified by IBM themselves. xxxxxxxx.snap.pax.Z
4. upload the renamed file (step 3) to our FTP server:

ftp server: ftp.XxxXxxx.ibm.com
login: anonymous
passwd:
upload dir: /toibm/aix

Hitachi Dynamic Link Manager on AIX manipulation command

Today's work lead me to find and learn new command for managing and verifying Hitachi Disks Array on AIX machine:

Source taken from http://www.coolcommands.com/index.php?option=com_cccat&task=display&id=47

hdlm - Hitachi SAN disk correspondance Description

Correspondance for physical disks for a Hitachi SAN:

4 hdisk = 4 dlmfdrv = 1 physical disk

HDLM commands:

Command to discover all dlmfdrv:

# dlmcfgmgr

Command to verify the disks on a HITACHI SAN:

- the system:

# dlnkmgr view -sys

- the drivers

# dlnkmgr view -drv

- the paths

# dlnkmgr view -path

Changing the Auto Failback feature

# dlnkmgr set -afb on
dlnkmgr set -afb on
Execute command? [y/n] : y
KAPL01001-I The HDLM command completed normally. Opestartration name = set

Changing the Path Health Checking feature

# dlnkmgr set -pchk on
dlnkmgr set -pchk on
Execute command? [y/n] : y
KAPL01001-I The HDLM command completed normally. Operation name = set

To bring LUN online in the system

# dlnkmgr online -path -pathid 000001

SSH Secure Shell: Protocol error: packet too long

Source taken from http://www.jp.ssh.com/support/faq/secureshell/qa_1_920.html

Unix and Windows: I receive error messages like this when trying to connect to a secure shell server: Server responded "Protocol error: packet too long: -130315592" (number reported will vary). Other similar error messages may also appear. How do I fix this?


The most likely cause of this error message is that you are attempting to connect to an older version secure shell server. Try changing the encryption algorithm to a different algorithm - for example, Blowfish.

Windows Client

Go to Edit -> Settings ... -> Profile Settings -> Connection , change the algorithm, click on OK. Then choose File -> Save Settings and they try again to establish a connection. If that does not resolve the problem, try changing the MAC Algorithm:

http://www.ssh.com/products/ssh/winhelp30/Connection.html

Unix Client

If you have root privileges, edit the /etc/ssh2/ssh2_config to change the encryption algorithm.

If you do not have root privileges, you can set the algorithm in your own user-specific configuration file, located by default in $HOME/.ssh2/ssh2_config . If you do not already have a user-specific configuration file, simply copy the file /etc/ssh2/ssh2_config to $HOME/.ssh2/ssh2_config .

You can also specify a different cipher or MAC at the command line using the ssh2 options -c and/or -m. See man ssh2 and man ssh2_config for more information.

Moving Data Between Volume Group (VG - HPUX)

# cd /
# cd /; fbackup -f - -i . | (cd /; frecover -f - -r)

How to check SSA card serial number

View SSA Serial No.:

# ssa_ela -h 3
ssa3 SRN 42521

Howto recovery from an unknow Root password

TITLE : Howto recovery from an unknow Root password
OS LEVEL : AIX 4.x and above

----------------------------------------------------------------------------

1. Boot the machine into 'service' mode from the installation media. Ensure
the CD/tape is in the appropriate drive, turn the keyswitch to 'service'
mode and boot the machine.
2. At the first screen, "Please Define the System Console", type a 1 and
press enter.
3. At the next screen, type 1 and press enter to have English during install.
4. At the next screen, "Welcome to Base Operating System Installation and
Maintenance", select 3 - Start Maintenance Mode for System Recovery.
5. At the "Maintenance" screen, select 1 - Access a Root Volume Group.
6. At the "Warning" screen, press 0 to continue.
7. At the screen, "Access a Root Volume Group", select the number for the
Root Volume Group to display the LV information and press enter.
8. At the "Volume Group Information" screen, select 2 -Access this Volume
Group and start a shell before mounting filesystems.
9. At the root prompt, type 'exit' to continue the process of accessing the
root volume group.
10. At the next prompt, set the TERM variable, using:

TERM=vt100 export TERM (where vt100 is the emulation used)

11. At the next prompt, change the root password, using:

passwd

You will then be prompted for a new root password. You will be asked
to enter it a 2nd time to confirm.

12. Shutdown and reboot the system in normal mode. Turn the keyswitch to
'normal' mode and type:

shutdown -Fr

Solaris login check

To check the status of the UNIX account.

# /usr/bin/logins -aoxl username

Checking disk mapping in Linux system

Below is the command to check the correct PV to scsi mapping in the Linux system:

# scsiinfo -a /dev/sda1

Checking Solaris hardware component

I've learned the command to check and verify Solaris's hardware component including ram, processor details, system model and architecture, network and etc. The command is the following below:

# /usr/platform/`uname -m`/sbin/prtdiag

Using public keys for SSH authentication

Source taken from http://www.putty.nl/0.58/htmldoc/Chapter8.html#pubkey

Public key authentication - an introduction

Public key authentication is an alternative means of identifying yourself to a login server, instead of typing a password. It is more secure and more flexible, but more difficult to set up.

In conventional password authentication, you prove you are who you claim to be by proving that you know the correct password. The only way to prove you know the password is to tell the server what you think the password is. This means that if the server has been hacked, or spoofed (see section 2.2), an attacker can learn your password.

Public key authentication solves this problem. You generate a key pair, consisting of a public key (which everybody is allowed to know) and a private key (which you keep secret and do not give to anybody). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine.

So you generate a key pair on your own computer, and you copy the public key to the server. Then, when the server asks you to prove who you are, PuTTY can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in. Now if the server is hacked or spoofed, the attacker does not gain your private key or password; they only gain one signature. And signatures cannot be re-used, so they have gained nothing.

There is a problem with this: if your private key is stored unprotected on your own computer, then anybody who gains access to that will be able to generate signatures as if they were you. So they will be able to log in to your server under your account. For this reason, your private key is usually encrypted when it is stored on your local machine, using a passphrase of your choice. In order to generate a signature, PuTTY must decrypt the key, so you have to type your passphrase.

This can make public-key authentication less convenient than password authentication: every time you log in to the server, instead of typing a short password, you have to type a longer passphrase. One solution to this is to use an authentication agent, a separate program which holds decrypted private keys and generates signatures on request. PuTTY's authentication agent is called Pageant. When you begin a Windows session, you start Pageant and load your private key into it (typing your passphrase once). For the rest of your session, you can start PuTTY any number of times and Pageant will automatically generate signatures without you having to do anything. When you close your Windows session, Pageant shuts down, without ever having stored your decrypted private key on disk. Many people feel this is a good compromise between security and convenience. See chapter 9 for further details.

There is more than one public-key algorithm available. The most common is RSA, but others exist, notably DSA (otherwise known as DSS), the USA's federal Digital Signature Standard. The key types supported by PuTTY are described in section 8.2.2.

For Unix, what are ssh-agent and ssh-add, and how do I use them?

Source taken from http://kb.iu.edu/data/aeww.html

In Unix, ssh-agent is a background program that handles passwords for SSH private keys. The ssh-add command prompts the user for a private key password and adds it to the list maintained by ssh-agent. Once you add a password to ssh-agent, you will not be prompted for it when using SSH or scp to connect to hosts with your public key.

To use ssh-agent and ssh-add, follow the steps below:

1. At the Unix prompt, enter: eval `ssh-agent` Note: Make sure you use the backquote ( ` ), located under the tilde ( ~ ), rather than the single quote ( ' ).
   
   
2. Enter the command: ssh-add
3. Enter your private key password.
   
   
4. When you log out, enter the command: kill $SSH_AGENT_PID To run this command automatically when you log out, place it in your .logout file (if you are using csh or tcsh) or your .bash_logout file (if you are using bash).

Note: The versions of these programs for SSH2, ssh-agent2 and ssh-add2, are the same as outlined above. To use them, follow the instructions above, replacing all occurrences of ssh-agent with ssh-agent2 , and ssh-add with ssh-add2 . The SSH2 versions will only work if both your computer and the remote host are running SSH2.