Setting file execute permissions--a somewhat arcane question.

Question

Level 4

2,301 points

Setting file execute permissions--a somewhat arcane question.

As I've been learning Unix, I'm often impressed by the logic and efficiency of certain features, so when I find things that don't fit this pattern, it really makes me wonder.

This particular example isn't so much about the design of permissions as it is about the way administrators--even competent ones--use them.

A case in point:

-rwxr-xr-x 1 root wheel 5099 Dec 7 2006 /usr/sbin/apachectl

This means that the file belongs to root, and root can do anything (s)he wants to it--read, write and execute.

Furthermore, anyone who belongs to the group, wheel (which, correct me if I'm wrong here, is pretty generally confined to root) can read and execute it. They can't write to it because, presumably, you don't want just any old wheel coming along and changing this file, although they may read it, which might be a good thing to do before they execute it.

Finally, other, that is, any old user, can execute the file, but they can't write to it, and they can't even read it. (Incidentally, why would you want to prevent someone from reading a file that you're allowing them to execute? Element of surprise? But that's not my real question.)

My real question involves the following: try logging on as anyone other than root and running that file. If Apache is running, try to stop it. It will tell you it isn't running. That's a lie. Okay, maybe an honest mistake, but it isn't true. Now try to start it. It doesn't have to be stopped; you'll get the same error either way: "fopen: Permission denied," it says, "httpd: could not open error log file /private/var/log/httpd/error_log."

I seem to run into this a lot. A file that I have permission to execute produces an error message when I try to run it because it tries to do something that I don't have permission to do. So why do I have permission to execute the file in the first place?

Okay, maybe there are some useful things I can do with apachectl, like configtest, that don't require me to be root. Like if I'm editing the httpd.conf file, I can check it with configtest, and then when it's ready I can go get an administrator to restart apache, or something like that. Except for the fact that I can't edit httpd.conf because I only have read access to that file. But maybe there are some imaginable scenarios where it might make sense.

But there are other files that you simply can't do a darned thing with, yet which still allow you to execute them and be chastised for your lowly permission status. Not only that, but it's a relatively simple matter to construct a script in such a way that it will check to see who is executing it, while it's processing directives, and return an appropriate error message, e.g. "Sorry, 'stop' and 'start' can only be performed by root," instead of allowing some downstream process to do its dirty work. Incidentally, allowing errors to be returned from downstream processes gives unprivileged users some insight into what the script does, which, presumably, is part of what they're trying to prevent by not allowing them to read the script!

If anyone can shed any light on why things are so often done this way, I'd appreciate it. If not, I guess this is just my Unix rant for the the week.

Disclaimer: I don't hate Unix. I really like it a lot, in spite of its quirks. No one is perfect; not even me! And don't even get me started on "Windows."

MacBook Pro 17, Mac OS X (10.4.10), 4 GB RAM, 160 GB HD

Posted on Aug 19, 2007 9:55 AM

Reply

Answer 1

red_menace

Level 6

17,066 points

Aug 19, 2007 11:27 AM in response to David Livesay

I'm no Unix expert by any means, but you see this kind of stuff with your Joe Average application all the time - Joe Average (probably from a Windows - or worse, Linux - background) develops his latest whiz-bang gizmo, but forgets about the multi-user aspect of the OS and just assumes that everyone runs with the same priviledges that he has. I ran into one just this morning - a non-admin application that assumed it was running in an admin account and tried to create a file in the /Library folder, which I didn't have access to becuse I don't normally run in an admin account.

I think it is just laziness on the programmers part, combined with various scripts and stuff coming over from other platforms. Hopefully the learning curve will be short (although it has been a few years already). Also, you can edit the httpd.conf file, you just need the permissions for the folder to save it there (as it should be).

Reply

Answer 2

Aug 19, 2007 2:01 PM in response to red_menace

I will try to explain in very simple terms for the two of you since you both admitted to be novices to using unix.

Unix permits the user to write scripts which can be used to execute unix commands. However, all of these commands, i.e. ls, cp, mv, cd, etc, are compiled executable commands. Programmers using a variety of languages such as c, cc, fortran, etc compile code and make executable programs. I am sure that you are familiar to Safari, Apple Mail, Word, Excel, ect - these are also examples of compiled code.

Now we will get to the heart of the matter - when a file is given the priviledges rwx rx rx it means the owner can read, write, and execute the file, and this also allows the owner to copy the file. The members of the group and others may read and execute the file, but cannot change. Unless it is a script you probably cannot read or understand the contents of the file. It also means you can not change the file. For most files it also means the group and others can copy the file, but they can not move it. This prevents outsiders from destroying the integrity of the directory.

When the owner is root you must be the administrator to read the file or try to modify or move it. This is to prevent the casual user from destroying the integerity of the operating system. In general, it is not nice to mess with root unless you really know what you are doing.

If anything I said offends you or hurts you feelings, I apologize. However, I hope you continue to learn how to use unix. It can be very rewarding 😉

Reply

Answer 3

red_menace

Level 6

17,066 points

Aug 19, 2007 2:33 PM in response to Stanley Williams

My feelings aren't hurt, and I appreciate your comments. As mentioned before, I am no expert, but I do have a basic grasp. My understanding of the OP's statements (I think), as well as my own, deal with how more and more people seem to be making assumptions about (or are just ignoring) the permissions of users that may be running their scripts or code. It is pretty silly to write a script that sorts mail that won't execute unless run as an admin user, or even root - if that is really needed, then access to the script or code should be limited to those with the proper permissions.

Reply

Answer 4

Aug 19, 2007 3:13 PM in response to David Livesay

Disclaimer: I don't hate Unix. I really like it a lot, in spite of its quirks. No one is perfect; not even me!

When you can write "I really like it a lot, because of its quirks" you'll know you've "got" it! 🙂

But, you're right, permissions are often mis-used, or badly set.

Reply

Answer 5

David Livesay Author

Level 4

2,301 points

Aug 19, 2007 9:07 PM in response to Stanley Williams

Stanley, I think you missed my point. It's not that I don't understand how permissions work. I just don't understand how some people apply them. It doesn't make sense to me to give someone permission to run a script if doing so only allows them to get an error message from a downstream process. Understanding Unix permissions as I do, it seems pretty easy to predict who will be able to run a script successfully, and there's no point in giving anyone else permission to run it. The permissions you assign to a script should be as restrictive as or more restrictive than the actions it invokes, but in practice, it seems like some people are just saying, ah well, I'll let everybody run this and count on the permissions on all the other files to prevent them from doing any serious damage. If everybody did that, Unix security would be... like Windows security. 🙂

I'm not that new to Unix. I'm new to shell scripting. I have been doing other kinds of programming for a few years now.

Reply

Answer 6

David Livesay Author

Level 4

2,301 points

Aug 19, 2007 9:13 PM in response to Michael Conniff

And when I've "got it," how do I get rid of it? 😉

I like idiosyncratic people and cats. I like my computers logical, predictable and transparent.

Reply

Answer 7

Aug 20, 2007 6:39 AM in response to David Livesay

Here is how I use permissions.

When I create a directory for a program I develop I set the directory permissions to rwx rx rx (chmod 755). The subroutines and such files have a directory permission of rw rx rx, and the generated absolute (program) has a permission of rwx rx rx. This means someone can read the code, copy the directory & its contents to their system if they can get access to the directory, but they cannot modify the directory or its contents.

Let's assume two such directories, one with code and one with input/output files and unix scripts. The data files will be given permissions of rw rx rx and the unix scripts would be given permissions of rwx rx rx. Once again, this means someone can read the code, copy the directory & its contents to their system if they can get access to the directory, but they cannot modify the directory or its contents. However, if they copy the directories (cp -r dir-name) and contents to their system they can modify the code and the unix scripts. (if they use cp -rp dir-name they cannot make changes - I am still the owner).

If I belong to a group none of the group may change anything in my directory where the permission is rwx rx rx. However, if the permissions for the directory and files are rwx rwx rx then anyone in my group may make modification to the files in my directory.

Now let's assume they have data and scripts in their directory and want to use the executable file in my directory. No problem - they can use the program to read the data and create output to their directory as long as they have acess to my directory with the executable file.

I hope this helps.

Reply

Answer 8

etresoft

Level 9

56,662 points

Aug 20, 2007 10:15 AM in response to David Livesay

Perhaps you just don't know all the details of that particular application. The default log location is in a directory that you cannot write to. However, this doesn't have to be the case. It could be anywhere.

There are only a few programs that only root should be able to run. Many have world execute permission explicitly so anyone can run it. That anyone may be a user who have no privileges at all (such as nobody or www) so that if something it gets hacked, the script kiddie only gets access to nobody's files. Usually, that "anyone" is one of these specific users. That log file is probably owned by and is restricted to that user.

Reply

Answer 9

David Livesay Author

Level 4

2,301 points

Aug 20, 2007 5:23 PM in response to etresoft

Perhaps you just don't know all the details of that particular application.

Please fill me in on the details I'm missing. That's why I posted this question.

The default log location is in a directory that you cannot write to. However, this doesn't have to be the case. It could be anywhere.

Yes, and the permissions could be anything, but for the current location, the permissions don't make sense. You should always write a script for the situation that exists, assuming anyone who had a reason to move the log file would also have permission to change the file permissions accordingly. It doesn't make sense to set permissions according to what someone might do at some future time.

There are only a few programs that only root should be able to run.

Please elaborate. Would this include apachectl in your view? If not, what reason would someone else have for running it when it is just going to fail? And remember, if you're going to say they can move the log file, I'm going to reassert that if they can do that then they can change the permissions accordingly.

Many have world execute permission explicitly so anyone can run it. That anyone may be a user who have no privileges at all (such as nobody or www) so that if something it gets hacked, the script kiddie only gets access to nobody's files. Usually, that "anyone" is one of these specific users. That log file is probably owned by and is restricted to that user.

I don't quite follow you. If "anyone" can run it, that would include root. If someone is trying to hack a system, and can choose whether to run a script as root or an impotent user, why would they choose to run it as an impotent user? If they can only do damage by running a given executable as root, they're going to run it as root, whether or not anyone else has permission to run it.

Reply

Answer 10

etresoft

Level 9

56,662 points

Aug 21, 2007 6:38 AM in response to David Livesay

David Livesay wrote:

Perhaps you just don't know all the details of that particular application.

Please fill me in on the details I'm missing. That's why I posted this question.

I will try. But it is easier to explain why "programs in general" behave a certain way than why a "particular" program might behave a certain way. In particulars, I'm likely to be wrong. In generalities, I'll be more correct.

The default log location is in a directory that you cannot write to. However, this doesn't have to be the case. It could be anywhere.

Yes, and the permissions could be anything, but for the current location, the permissions don't make sense. You should always write a script for the situation that exists, assuming anyone who had a reason to move the log file would also have permission to change the file permissions accordingly. It doesn't make sense to set permissions according to what someone might do at some future time.

Sure it does. To use your apachectl example, Apache can be setup to put its log files anywhere on the system. It can be setup to use any particular user. It is one of the most configurable programs there is. It is "owned" by root so that it can't be messed with. It is "run" by nobody or www, so that, if it is compromised, it won't cause (much) damage. On Unix, there is no way to specify that a program is owned by one particular user and run by another particular user (well, maybe with ACL). For this program, the executable could be owned by www, but, since that user is configurable, that wouldn't make any sense. Plus, user ids are specific to each machine, only root is always uid 0. Plus, it is common practice for various reasons to start up as one user and either promote/demote to a different user. Plus, there are at least a dozen other process and daemon specific details that I'm ignoring. I'm trying to make it as short and sweet as possible.

There are only a few programs that only root should be able to run.

Please elaborate. Would this include apachectl in your view? If not, what reason would someone else have for running it when it is just going to fail? And remember, if you're going to say they can move the log file, I'm going to reassert that if they can do that then they can change the permissions accordingly.

I don't know the low-level details about apachectl in particular. Usually, any daemon or daemon related program can only be started by root, but is actually run as a different user. And while I say "only", that is not true. It is more correct to say "should". Everything is configurable! I might want to test out Apache 3.0, for example. I will have it configured to run as a regular user instead of root, because I am debugging it.

Usually, it is only very low-level, hardware programs (like fsck) that can only be run as root.

Many have world execute permission explicitly so anyone can run it. That anyone may be a user who have no privileges at all (such as nobody or www) so that if something it gets hacked, the script kiddie only gets access to nobody's files. Usually, that "anyone" is one of these specific users. That log file is probably owned by and is restricted to that user.

I don't quite follow you. If "anyone" can run it, that would include root. If someone is trying to hack a system, and can choose whether to run a script as root or an impotent user, why would they choose to run it as an impotent user? If they can only do damage by running a given executable as root, they're going to run it as root, whether or not anyone else has permission to run it.

You can't choose who to run a program as (unless you are root). A program is owned by whomever owns it. It is run by whomever is logged in. Apache, for example, runs "as" www. If hacked, all they can do is deface your web page, they can't bring down the server or compromise it in any other way. That is also why you shouln't even have root enabled on your system and why you should say in su or sudo mode for very long.

Reply

Answer 11

b3and88

Level 1

70 points

Aug 21, 2007 8:08 AM in response to David Livesay

Your gripe with the permissions on apachectl is trivial and not particularly valid. You'll find that even fsck will be mode 555 or 755. And it will barf if a regular user tries to run it on a hard drive filesystem. But that's not the only use for fsck. A mortal user is free to create a virtual disk with a file system and use fsck on that. That's the way it's been in unix for all time. Even if the default usage of a command requires root to work properly, there are often legitimate ways to use that program on alternate files. Thus, things are most often protected by making sure system files, directories, devices, and the like have appropriate modes set, and not by restricting execute permission on programs.

You're free to make apachectl mode 700, if you like. You could make a new group called webadmin, and make apachectl mode 4750, owned by root and webadmin. Then users you add to the webadmin group could run apachectl as root. This is the sort of stuff that system administrators do to make a vanilla system their own.

Even though I've got 30 years of unix experience, I wouldn't dream of making such changes until I understood completely and precisely how OS X uses users, groups, and permissions. The basics have been the same since the beginning of time, but each system has subtle differences.

If you had griped about how stupid apachctl is, then you'd have a good case to make. You're free to fix it or rewite it. Do a good job and the apache folks will probably be grateful.

Reply

Answer 12

David Livesay Author

Level 4

2,301 points

Aug 21, 2007 3:57 PM in response to etresoft

To use your apachectl example, Apache can be setup to put its log files anywhere on the system. It can be setup to use any particular user. It is one of the most configurable programs there is. It is "owned" by root so that it can't be messed with.

You just contradicted yourself. Yes, it is configurable, but only by root or someone with root permissions, because it is, as you say, "'owned' by root so that it can't be messed with." "Configurable" = able to "be messed with." No one who isn't able to edit httpd.conf is going to be able to make those changes, so why allow them to execute apachectl? If they can edit httpd.conf then they can change the permissions on apachetl, but they wouldn't even need to because they can use sudo. Limiting execute permissions to root would only prevent users from running it who would only get an error anyway.

You can't choose who to run a program as (unless you are root).

Sure you can. You can su to another user or sudo to run a command as root, assuming you have permission to do so.

Apache, for example, runs "as" www. If hacked, all they can do is deface your web page, they can't bring down the server or compromise it in any other way.

They can stop the server by running apachectl stop, unless they get an error from a downstream process, but if that fie didn't have o+x permission they wouldn't even be able to do that. The permissions on the executable itself would stop them instead of some contingent, subsequent command that someone may have changed, for example by moving the log file, without realizing the consequences. Now isn't that how it's supposed to work?

Reply

Answer 13

David Livesay Author

Level 4

2,301 points

Aug 21, 2007 4:10 PM in response to b3and88

Your gripe with the permissions on apachectl is trivial and not particularly valid.

Sorry I wasted your time then. Next time you can just pass by my post without reading it. How's that?

If you had griped about how stupid apachctl is, then you'd have a good case to make.

Wait. What are you saying? That apachectl is stupid but the permissions that are set on it are brilliant? I have to say that I disagree with you there. apachectl is pretty clever, although it could be improved upon. For example, if I have a script that can be run by anyone, but some actions will only work if you have root permissions, I include this code for those actions:

if [ "$USER" != "root" ]; then
echo "You must run $0 as root to $ARG."
exit 1
fi

Reply

Answer 14

etresoft

Level 9

56,662 points

Aug 21, 2007 5:19 PM in response to David Livesay

David Livesay wrote:
For example, if I have a script that can be run by anyone, but some actions will only work if you have root permissions, I include this code for those actions:

if [ "$USER" != "root" ]; then
echo "You must run $0 as root to $ARG."
exit 1
fi

I told myself I wasn't going to respond on this thread again. Then I saw that code. We are amused.

Consider the following:


Last login: Tue Aug 21 19:13:40 on ttyp1
Welcome to Darwin!
medusa:~ jdaniel$ echo $USER
jdaniel
medusa:~ jdaniel$ export USER=root
medusa:~ jdaniel$ echo $USER
root
medusa:~ jdaniel$

then, get yourself a good UNIX book and learn how it all works.

Reply

Answer 15

Aug 21, 2007 6:25 PM in response to David Livesay

This is an interesting thread.

What your running into is the fact that file permissions have little if anything to do with system privileges. Every file has file permissions and they are usually dictated by where they reside in the file system and/or the umask (which is beyond this discussion). File permissions dictate where you can go, what you can read/write/execute, but not how you can interact with the system.

The file in question here has 755 permissions meaning anyone can read or execute it, only root can make changes. Why? Mostly because that's what everything else gets in /usr/sbin, and there's no reason not to use those permissions. The file permissions have nothing to do with the privileges needed to allow the file to do what it does. If the file needs access to hardware or parts of the file system only accessible by root, you will get an error if you try to execute. You'll still be able to access the help section though, and anything else that doesn't require root privileges.

A better example is ifconfig. There's a ton of things you can do with it to get information about your network connections, but you have to be root to enable or disable an interface.

The is basic least privilege user concepts. Windows uses it in some areas, though not very well until Vista, and even that isn't as "predictable" in behavior as UNIX.

Reply