Special permissions in Linux (SUID, SGID, Sticky Bit)

There are 3 Special permissions commonly used in linux.

1) Set User ID i.e. SUID (only for command binaries)
2) Set Group ID i.e. SGID (for command binaries and directories)
3) Sticky Bit (only for directories)

SUID (Set User ID) : When a SUID bit is set on a command then that command always executes with the User ID of its own user owner (who created it) instead of the user who is executing it.

Eg: The binary of passwd command has SUID permission set on it, that is why, when unpriviledged users execute this command, it always executes with the UID of "root" and changes their password in /etc/shadow (which is only readable or writable by root).

To set SUID on a program, run:


#chmod u+s /usr/bin/test    or
#chmod 4744 /usr/bin/test







SGID (Set Group ID)(on command binary) : When SGID permission is set on any command, then that command runs with the Group ID of group owner of the command's binary instead of GID of the user who is executing it. To set SGID on a program use the following command

#chmod g+s /usr/bin/test or
#chmod 27xx /usr/bin/test


SGID (Set Group ID)(on directories) => When SGID permission is set on a directory, then all the new (future) files created under that directory will have the same group owner as that of the parent directory. Moreover subdirectories (created in future) will also have SGID bit on them. Example: If we set SGID on a directory, for example: on /tmp/test with group owner as "varu", now if another user "smith" creates any file in /tmp/test directory then the user owner of this file will be "smith" but group owner will be "varu" because of SGID on parent directory. To set SGID on a directory



#chmod g+s /usr/bin/directory or
#chmod 27xx /usr/bin/directory


Sticky Bit : The new files created under the directory having Sticky Bit on it can be only deleted by root or the user who created that file. No other user can delete that file even if they have write permission on the parent directory. EXAMPLE: /tmp directory is having Sticky Bit permission on it, that is why the content under this can be only deleted by root or the user owner of the content/file. To set Sticky Bit on a directory,

#chmod o+t /tmp/
#chmod 1777 /tmp/


 Learn & share
 Rzm

SGID (Set Group ID)(on directories) => When SGID permission is set on a directory, then all the new (future) files created under that directory will have the same group owner as that of the parent directory. Moreover subdirectories (created in future) will also have SGID bit on them. Example: If we set SGID on a directory, for example: on /tmp/test with group owner as "john", now if another user "mike" creates any file in /tmp/test directory then the user owner of this file will be "mike" but group owner will be "john" because of SGID on parent directory. To set SGID on a directory, run: - See more at: http://www.switchroot.com/special-permissions-in-linux-suid-sgid-sticky-bit#sthash.7nf8pcST.xew4OaOM.dpuf

Apart from traditional file permissions in linux,there are three types of special permissions:
1) Set User ID i.e. SUID (only for command binaries)
2) Set Group ID i.e. SGID (for command binaries and directories)
3) Sticky Bit (only for directories)
SUID (Set User ID) => When a SUID bit is set on a command then that command always executes with the User ID of its own user owner (who created it) instead of the user who is executing it.
EXAMPLE: The binary of passwd command has SUID permission set on it, that is why, when unpriviledged users execute this command, it always executes with the UID of "root" and changes their password in /etc/shadow (which is only readable or writable by root).
To set SUID on a program, run:
- See more at: http://www.switchroot.com/special-permissions-in-linux-suid-sgid-sticky-bit#sthash.7nf8pcST.xew4OaOM.dpufApart from traditional file permissions in linux,there are three types of special permissions:
1) Set User ID i.e. SUID (only for command binaries)
2) Set Group ID i.e. SGID (for command binaries and directories)
3) Sticky Bit (only for directories)

SUID (Set User ID) => When a SUID bit is set on a command then that command always executes with the User ID of its own user owner (who created it) instead of the user who is executing it.

EXAMPLE: The binary of passwd command has SUID permission set on it, that is why, when unpriviledged users execute this command, it always executes with the UID of "root" and changes their password in /etc/shadow (which is only readable or writable by root).

To set SUID on a program, run:

Apart from traditional file permissions in linux,there are three types of special permissions:
1) Set User ID i.e. SUID (only for command binaries)
2) Set Group ID i.e. SGID (for command binaries and directories)
3) Sticky Bit (only for directories)
SUID (Set User ID) => When a SUID bit is set on a command then that command always executes with the User ID of its own user owner (who created it) instead of the user who is executing it.
EXAMPLE: The binary of passwd command has SUID permission set on it, that is why, when unpriviledged users execute this command, it always executes with the UID of "root" and changes their password in /etc/shadow (which is only readable or writable by root).
To set SUID on a program, run:
- See more at: http://www.switchroot.com/special-permissions-in-linux-suid-sgid-sticky-bit#sthash.7nf8pcST.xew4OaOM.dpuf

Apart from traditional file permissions in linux,there are three types of special permissions:
1) Set User ID i.e. SUID (only for command binaries)
2) Set Group ID i.e. SGID (for command binaries and directories)
3) Sticky Bit (only for directories)
SUID (Set User ID) => When a SUID bit is set on a command then that command always executes with the User ID of its own user owner (who created it) instead of the user who is executing it.
EXAMPLE: The binary of passwd command has SUID permission set on it, that is why, when unpriviledged users execute this command, it always executes with the UID of "root" and changes their password in /etc/shadow (which is only readable or writable by root).
To set SUID on a program, run:
- See more at: http://www.switchroot.com/special-permissions-in-linux-suid-sgid-sticky-bit#sthash.7nf8pcST.xew4OaOM.dpuf

Error: Error: The Yum utility failed to install the required packages. Attention! Your software might be inoperable. Please, contact product technical support.

Hi all,

I encountered the following error with Yum while Plesk upgrade. This was mainly seen when a direct upload from plesk 8.6 to 11 was tried by the customers.

"Error: The Yum utility failed to install the required packages.
Attention! Your software might be inoperable.
Please, contact product technical support."



The issue occurred due to the following so file soft links.
-------------------------------------------------------------------------------------------------------
xxxx-bash-3.2# ls -al /usr/lib/libz*
-rw-r--r-- 1 root root 101462 Aug 23 09:13 /usr/lib/libz.a
lrwxrwxrwx 1 root root     13 Dec 21 02:23 /usr/lib/libz.so -> libz.so.1.2.5
lrwxrwxrwx 1 root root     13 Dec 21 02:23 /usr/lib/libz.so.1 -> libz.so.1.2.5
-rwxr-xr-x 1 root root  73580 Jan 10  2007 /usr/lib/libz.so.1.2.3
-rwxr-xr-x 1 root root  95004 Aug 23 09:13 /usr/lib/libz.so.1.2.5
-------------------------------------------------------------------------------------------------------

Replacing the soft links in the server with the command ln -s helped me

Command summary after soft link was replaced.
------------------------------------------------------------------------------------------------------
xxxx-bash-3.2# ls -al /usr/lib/libz*
-rw-r--r-- 1 root root 101462 Aug 23 09:13 /usr/lib/libz.a
lrwxrwxrwx 1 root root     13 Dec 21 02:23 /usr/lib/libz.so -> libz.so.1.2.3
lrwxrwxrwx 1 root root     13 Dec 21 02:23 /usr/lib/libz.so.1 -> libz.so.1.2.3
-rwxr-xr-x 1 root root  73580 Jan 10  2007 /usr/lib/libz.so.1.2.3
-rwxr-xr-x 1 root root  95004 Aug 23 09:13 /usr/lib/libz.so.1.2.5

xxxx-bash-3.2#yum clean all
------------------------------------------------------------------------------------------------------

If the reported steps does not do the trick for you .
You can also try to reinstall the yum Packages with rpm.

Command summary
---------------------------------------------
 #cd /usr/lib
#ln -s libz.so.1.2.3 /usr/lib/libz.so
#ln -s libz.so.1.2.3 /usr/lib/libz.so.1
---------------------------------------------

Reference:http://pads.tiddlyspace.com/YumSegmentationFault

Learn & Share
rzm

Script to monitor tomcat service

 Hi all,

This is a small script which could be used to monitor tomcat service is webserver to prevent down time if the tomcat service goes down. It helped me once to maintain the tomcat service in running status for a customer who had problem with tomcat service going down intermittently.

Script

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

#!/bin/bash

#

CHECK_URL="http://example.com/index.jsp"
CHECK_KEYWORD="synosure"
MAXTRIES=2
SLEEPTIME=1
LOGFILE=/var/log/tomcat_check.log
TOMCATSH=/etc/init.d/tomcat

### Functions -----------------------

# check for a few times

function checkTomcatUp {
_maxtries=$1
for (( i=0; i<${_maxtries}; i=i+1 ))
do
/usr/bin/curl -s -m 30 "${CHECK_URL}" | grep "${CHECK_KEYWORD}"

> /dev/null

if [ $? -eq 0 ]
then
exit 0
fi
sleep ${SLEEPTIME}
done
}

### ---------------------------------

checkTomcatUp ${MAXTRIES}

# perform tomcat restart

echo `date` "--- Restarting Tomcat ---" >> ${LOGFILE}

# stop tomcat

echo `date` "Stopping Tomcat..." >> ${LOGFILE}

#${TOMCATSH} stop

# wait a while, then check if really stopped

#sleep 2
pid=`ps auwwx |grep "org.apache.catalina.startup.Bootstrap" |grep -v
grep|awk '{print $2;}'`
while [ "X${pid}" != "X" ]
do
echo `date` "Killing Tomcat, PID=" ${pid} >> ${LOGFILE}
kill -9 ${pid}
sleep 2
pid=`ps auwwx |grep "org.apache.catalina.startup.Bootstrap" |grep -v
grep|awk '{print $2;}'`
done

# start tomcat

echo `date` "Starting Tomcat..." >> ${LOGFILE}
${TOMCATSH} start

# give tomcat some time to start background processes

sleep 5

# just do 1 more check

checkTomcatUp 1
echo `date` "Giving up... waiting for next cron" >> ${LOGFILE}

exit 1
-------------------------------------------------------------------------------------------------------------------------------

Brief of script:

 This script basically checks whether the website is up by using the curl command which will download the page like a normal browser in the command prompt (note that it will be in html format). Now i check for a key work of my choice in it. It could be any word included in your index page. The MAXTRIES variable in this example helps us to limit the no of checks done.



Learn & share
rzm