Hi All,

setuid;
can i set uid on files and directories ?? if not what will happen if a uid is set on a file.
if uid is set on a executable, will users other than the owner will be able to delete and modify the executable ?
stick bit: does the concept of sticky bit mean only the owner will be able to delete the file in that directory?
if a dir has write permissions to others, will others group be able to delete the files if no sticky bit is set?

how do i determine if an os is 32 bit or 64 bit if uname -a does not give appropriate info.

regards,
Awaiz.

SUID:
=======
SUID is generally set for executables... suppose u have an executable file "/hello" with owner and group both as root, and u set an SUID to this executable, the concept is that, (wt i believe),

when u execute the above file as a normal user, say joe:

[joe@localhost ~]$ cd /
[joe@localhost /]$ ./hello

then the /hello is executed as if root is executing it (i.e., it's owner is executing it)..

To modify or delete a file set by SUID depends on the "write" permission of the file set to others.

sticky-bit:
=============
The concept of sticky bit comes mainly in an environment where, say 3 users in the same group (i.e, have same secondary group) are sharing a directory .. say /shared

In this case, first the group of the dir. is changed using:

[root@localhost /]# chgrp mygroup /shared

Not to say, the user's sec. group should be "mygroup"

Then add SGID to this dir. using :
[root@localhost /]# chmod g+s /shared

Now, every file created in this directory would have group as "mygroup" , and have rw permission for mygroup.

In this case, any user in the mygroup can read, write or delete files in this directory...

When we have to restrict, like, only the user who created the file should delete it, but he can view/change other files in the same directory, the stickybit is implemented.

[root@localhost /]# chmod o+t /shared

This prevent other users in the same group from deleting files that dont belong to them.. however they can make changes to others files...

But ofcourse, this restriction is not considered when root tries to delete a file here... As u know, root has the complete power!!

I think this should help u know sticky-bit n SUID...

If a directory has the sticky bit set, then you can't delete someone else's files. This is how the /tmp directory is created. This allows all users to create files there. If you don't want someone else to be able to make changes to your own file, then change the permissions of the file itself to prevent it. Deleting a file writes to the directory and not the file itself. ( To the kernel, a directory is a file ) That is why the sticky bit is needed for world writable directories, because without it someone with write access to the directory could delete any file.

Hi Vimal,

Do these special permissions work only on specific kernel versions?? coz i have tried setting up these permissions on EL4(dont remember the version of the kernel)but dont seem to work.
any idea ??

Awaiz.

Attention: SUID is NOT generally set on executables, as mentioned above.
This would be a big securtity flaw, as a simple buig in an application yould be used to execute harmful code with root rights.
SUID is often used for applications that i.e. need direct access to hardware devices that are normally only accessible to root.
shell scripts can't be set SUID for security reasons.

the SGID and sticky descriptions above seem to be right.

The suid, sguid bits are standard in Linux and Unix unless you have a very old Unix. There are some other permission features which you may not have or are not supported by the filesystem. One example is ACL's. They allow you to use the setfattr and setfacl commands to add more granularity to the permission system.
Using ACLs you can set permissions for certain users and groups. You can give groupA and groupB and user mikes full access and give groupC and user sallyg read-only access. The ext2 and ext3 filesytems allow you to use additional file attributes such as immutable. ( man lsattr, man chattr ). The selinux kernel adds a security model where you can control which process is allowed to alter a file. Even root can't change such a file in this case. Fedora Core uses a kernel with SELinux by default.