Seth Arnold said: > Note that your life may be significantly easier if you put all untrusted > users in one group, trusted users in another group, and fiddle with > group and world execute permissions on all the executables on your > system. The executables anyone can run (e.g., pine) can be made world > executable. The executables only trusted users can run can be made owned > by their group, and group executable.
This can be an effective strategy, but the way you describe it is actually a little more complex than it needs to be. You do not actually need to have a trusted group; you only need an untrusted group. The key here is the often overlooked fact that groups can be used to TAKE AWAY privileges as easily as they can be used to grant access. This is because of the way Unix permissions work. If you are the owner of a file, when permissions are checked, the kernel will look at the owner permissions only, and make access decisions based on those. If you are not the owner, it will next look to see if the group of the file is one you belong to (exactly which groups it checks, e.g. primary and/or auxilliary, is somewhat dependent upon implementation). If you do belong to the group that owns the file, the kernel will look at the permissions for the group AND STOP THERE, and make access decisions based on those permissions, REGARDLESS OF LESS RESTRICTIVE PERMISSIONS FOR "OTHER." So, for example, if you had a group "untrusted" that you didn't want to access a particular executable, say, /bin/false, you'd set the permissions like this: -r-x---r-x 1 root untrusted 4436 Jan 16 2001 /bin/false Anyone in the untrusted group can now no longer run /bin/false. Everyone else, not being a member of the untrusted group, can run it as they please. -- Derek Martin Senior System Administrator Mission Critical Linux [EMAIL PROTECTED]
