That's it. I've tried various locations in the past, including /usr/local/bin, /usr/local/sbin, usr/local/bin/myscripts, /home/myaccount/bin... I just can't find any place completely satisfying. The point is: I do not want to put custom shell scripts in /home partition because much of these are systemwide admin scripts, and also because I mount my /home filesystem with noexec option following the security considerations. I do find it logical to put those in /usr/local/bin (and some of them in /usr/local/sbin), however I hesitate doing so as it conflicts with the point of mounting /usr partition readonly, and as many programs place their binaries in /usr/local/bin by default, making too much clutter. I assume I could deal with the latter by using a dedicated subdir like /usr/local/bin/scripts or the like (or specifying --prefix=/usr compile-time option to the programs' .configure scripts, albeit doing so possibly conflicts with the FHS), however ad-hoc remounting /usr readwrite whenever I intend to write, test and debug a script (and remounting readonly again when the job is done) simply isn't too feasible a solution, and not much secure either (in my opinion that is). Is there any known commonly agreed-upon practice for the placement of custom shell scripts, that is as much secure and as much distribution-agnostic as possible? I'd like to hear your opinions.

Thanks for your time,
BILMO

Please note that noexec is not "intended" to be used for security purposes. It does provide a measure of security but does nothing to prevent shell scripts from being run. You can't run them directly but you can just type "sh scriptname" or through another method. There is nothing in place to stop that. What noexec does do is prevent "binaries" from being run and that is a wise thing for the most part.

Traditionally, /usr/local was for local scripts... so /usr/local/bin and /usr/local/sbin would be the right place for them. I recognize your frustration about it being mounted read-only (of course, they don't expect you to be changing these things daily once you move them there... only during testing). You could always mount /usr/local as it's own partition and allow it to be read-write but that's not really a good solution.

As for it being insecure to make /usr +rw for a bit then switch back to -ro ... it's not really that bad. Obviously you want to minimize the time it's writable but the only security implication involved is that no program should "write" to /usr without being told to. The odds are that if a script or local user has the rights to write into /usr, you probably already have a problem. I personally keep it read-only because it does prevent the problem. But even I remount it read-write when doing upgrades or patching programs... it keeps the window of opportunity as small as possible.

The distribution agnostic place would be in /usr/local/{,s}bin and the best idea is to write, test, and debug a script outside that directory and then move it into there. You wouldn't want someone running the script before you were done testing it... so you wouldn't want it in a place where it's in the path of all the users.

I'd use ~/bin for testing and development. And when you're pretty sure it's right... move it to /usr/local. And you can keep /home mounted with noexec (although I honestly have far too many personal scripts and programs to survive with that restriction myself) and just call them with "{interpreter} scriptname" until you're done debugging it.

Edit: Also note... shell scripts are not setuid... so they run with the rights of the user calling them. And no matter where you put them, if users can find them, and they have the rights to execute them, you have to assume they will.

I'd use /usr/local/... or /opt/...

Thanks for your feedback guys. And special thanks to frob23 - your elaborate explanation gave me much insight into what I hadn't gotten quite correctly before, and reminded me of some things I used to know.

Thanks,
BILMO