I was trying aliases, but basically I want to know how to make a user have to use my script (ie my configure script) instead of whatever one they are trying to use. I want to use this to protect them from installing things globally, so in this case, whenever they try running '/.configure', I want it to refer to my configure script, which then calls theirs, but adds the --prefix=$HOME/bin option.
I wanted to make this a more broad question, but I am not sure exactly which unix property I am refering to. I tried setting a configure alias, but of course that didn't work. I tried pre-pending my own bin directory with the configure script into PATH and doing an export, but it doesn't cover cases like if they run ./configure
Well, perhaps I need to rephrase that. I don't want them to install things where ./configure will normally install things. I want to keep the installs going into a special directory. It is part of a package manager app that keeps track of old installs, etc, so multiple version of say perl can be used. So if the user says:
./configure
make
make install
-> that needs to install in $HOME/apps/metapackage/packagename/packageversion
--so it is not particularly the user say, but the application used by that user, that needs to set all this up for them. The application take conf files the user specifies, and interprets how to do installs for them, by the user specifying install commands in the conf file (./configure, make, make install, etc). When using the app, the user will then lose their power to install anywhere. The application makes them install in a particular area. Otherwise, they need to not use the app.
The only place a "normal user" should be able to install software, is in their own home directories or to other directories where they have priviliges.
I think it's best when only the sys admin, or selected users control what's installed on the system, not any user.
I was hoping someone else would chip in here with a solution, because I don't know how you could do what you're asking using shell scripting. At least not securely.
Yes the application, if not the admin (and certainly not the user) should set this up and control the install. You could, for example, chmod the application to allow the user to run it as root. Then the install could write the files it needs, as well as update any system information. But this is no good as soon as you allow the user to run his own configure scripts, etc., as they would also run as root. I really think it's best that only admins and selected users control software installations.
Agreed. I guess, don't look at it as a security standpoint. Look at it as a convenience standpoint. During application run, the only place installs are allow to go are the directories specified by the application. This is for accounting by the application only, so it doesn't have to search the entire system for installs; the application will only care about the ones in the apps directory.
I would actually count on the users getting this part wrong almost consistently. Sorry, but that is what I have to say about the users.
However, what I can count on them is saying some sort of command like this -
python update_packages.py -p package_name -v version# -m metapackage_name -c
(-> -c equals 'create')
-and having this in their config file for the package:
configure (or for perl packages: perl Makefile.pl)
make
make install
Paths are something they will probably be sure to get wrong.
Thanks guys.
---------- Post updated at 02:10 PM ---------- Previous update was at 02:08 PM ----------
To add to that, I am have currently just made sure to send all commands through a python function which does this check for me. But if the use of commands gets widespread through the package manager program, then this could add more redundancy, than say setting something on the environment level.
Sorry, but that is what I have to say about the users.