I want to ensure that users of my system are incapable of chmodding files +x, and I do not want anything in /home/ or /var/ to be executable.

I can't put them on separate partitions.

Running Ubuntu 9.04 Server.

  • 3
    Got to ask, 'why?'. Seems an odd restriction to me and there might be a different way of approaching the problem.
    – CK.
    Jun 1 '09 at 14:05
  • 1
    I agree - what's the point of restricting the hell out of users? I know a shell account provider, rootshell.be, that has a lot of such "security" - and it's still possible to get around.
    – user1686
    Jun 1 '09 at 18:08

I was going to suggest a wrapper to chmod or something, but the more I think about it, the users will eventually find a way around this (scp an executable from another box, or run perl -s "chmod('FILE');", etc...

So, I think the FS method is the best. Since you say you can't move them to a new file system, what about using a --bind mount to "remount" /home and /var without exec privileges?

mount -o noexec --bind /var /var
mount -o noexec --bind /home /home

I'm not sure if that would work or not, but seems promising...

Well, I like my nice, shiny "nice answer" badge from this answer, but after playing with it I don't think it will work. My original test was on an old (2.4.9) kernel, and the "mount on top of itself" functionality appeared to work. I tried it again with a newer kernel (2.6.18) and it does not appear to work. I started to look at work arounds (like renaming /var and /home to something else and then mounting them back. I didn't get very far though because I found this in the man page for mount on the newer box:

Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed by passing the -o option along with --bind/--rbind.

Oh well... --bind is still a fun option...

  • 1
    I feel like there would be problems attempting to bind mount a partition over itself. I would recommend pretty dang thorough testing before rolling this out into production.
    – Scott Pack
    Jun 1 '09 at 15:03
  • Modify /etc/fstab and add noexec to the options field so noexec is used every time the machine starts and the filesystem is mounted. Jun 1 '09 at 15:27
  • Did this actually work? The answer seems to indicate that it might work. Has anyone confirmed?
    – pcapademic
    Jun 1 '09 at 23:26

I can think of 2 ways of doing this, one dirty, and one good. Let's start with the dirty.

Write a shell script that runs very regularly as a cronjob, say every 5 or 10 minutes. It would explicitly remove the exec flag from all files in those two directories, i.e.

chmod -R ugo-x /home /var

The better way is to do it at the filesystem level. Create new partitions to house both var and home, this is considered best practice anyway. Then add the ‘noexec’ option to mount. This will prevent, at the filesystem level, the execution of files stored within those directories.


This is a perfect example of the kind of question that should be answered thusly:

You seem to have come up with a solution for a complex problem, and are now asking specific questions on how to implement this solution. Could you please instead describe the original problem you are trying to solve?

My experience is that it's pretty important for a sysadmin to know when to respond to a request with "what? why?". How important depends on the propensity of the users to describe their original problem or to attempt to come up with their own solutions and ask for assistance in implementing them. In certain environments, it's the difference between expensive catastrophically bad solutions, and cheap good solutions.


don't forget to make sure /tmp /var/tmp and other user-writable dirs also are on the partitions mount with noexec flag.


Guess you can also use inotifywait with -r, -m and -e attrib options to reset -x flag if it is set by users


Sounds like you have a policy problem...
... and presumably this was caused by a real problem vs you being paranoid.
Aren't you limiting the effectiveness of the computing platform by doing this?

many scripts can be run by simply invoking the interpreter directly:
sh ./mybashscript.sh
perl ./myperldaemon.pl

So presumably you are trying to prevent a native executable from running?

Best to deal with this problem via policy and policing/auditing...
at best, you'll only keep the less experienced users at bay anyway.

  • you can run dynamically linked native executables even if they are not executable, by invoking /lib/ld-linux.so with the right parameters. This is not a bug, but a feature, so that you can call for example ln -s (which is dynamically linked) to link /lib-foo to /lib, while ln -s cannot find the libc (because it is in /lib-foo and not in /lib).
    – mihi
    Jun 1 '09 at 21:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.