Hi,
I would like to install the new ATI graphics card drivers. But the instructions demand that you do it as root.
Is there any way to fool an app/script into think that you are running it as root?
If I could do this as an unprivileged user the app/script would probably blow up, but each time it blew up I'd hopefully be able to spot why and fix each problem by themselves (for example, updating/overwriting files - I would be able to make backups before allowing it to overwrite them).
The only way I can think is to tar-ball the whole system apply the script, diff the date/times of each file to check for updates. But that seems overkill.
Any ideas?
If there is a solution I'd be able to apply it to other closed source installations that demanded super user rights (citrix client...).

Ta

David

well it needs to install the drivers into the filesystem, and if you modify your filesystem to allow a non-root user to write to /usr then you undermine the logic of non-root accounts and the whole security model. Why on earth would you not want to do this as root?

I don't get what you're trying to accomplish here at all.

The main reason an install script has to run as root is usually because the files it installs go in system directories. But when it comes to video card drivers there are also kernel modules involved. I doubt there's any way that you could ever get something like that to run as a non-privileged user.

Besides, if it were that easy to bypass root requirements when installing software, there wouldn't be much in the way of system security, would there? And if you can do things like tarball and restore the whole system, then you must already have root access, so why are you trying to bypass it?

hehe. Right what I'm trying to do...
If I run a closed source script/app as root, who knows what it's doing. It could screw your system. If you are paranoid then you can no longer trust your system.
So what I want to do is run the script/app as non-root. If I do that it will fail the first time it tries to update a file. At that point I take a backup of that file. Then (as root) I change the properties of that file so that the un-priv user can write to it.
Then I go back to the script (as un-priv user) and re-run it. It then manages to overwrite that one file, but it fails on the next one.
And so on and so forth.
At the end of the potentially long process I have a list of updated files and a backup of each one.
The last step would be to put the original rights onto each of the updated files.
So you see, I wouldn't be giving unpriv users access to all files, just a single user X the rights it needs to update the necessary files.
Paranoid? probably.
Is there a way though.

Ta

David

OK, but many of these programs amend existing files as well as create new ones and if you miss one, or it doesn't work the way you wish, you risk messing up your system. Why not just take a comprehensive backup and then do the install, you can then roll back if it doesn't work.

But if it's running as an unpriv user (lets call the user 'temp-installer') any new files will be owned by 'temp-installer'. Any old files that are changed I'd have to (after backing up) change ownership to 'temp-installer' so that a rerun will be able to perform the updates.
At the end I should have a trail of new files, and updated files currently owned by temp-installer.
I think it would be safer running the script as an unpriv user than backing up the whole system and running the script as root.

If you don't trust the script that comes with a driver, then you should not trust the driver, either. Just run the script as root and be done with it.

Well then let's call this an academic exercise. Can it be done or not? I'm not asking if it's a good idea. Just whether it can be done, and how it might be done if the answer is yes.
Saying "Be done with it" is a bit defeatist isn't it?
Let's say all I want to do is know what this script updates and adds to my system. If all I have to go on is files that are newer than the date I ran the script, I don't think that's good enough. And any new files will probably have the date that the file was created, and not installed therefore it'll get through the net.
Ta
David

Set up a virtual machine/emulator and run the script on a separate OS installed there. Then you can research everything to your heart's content without affecting your main machine.

Perhaps the answer is is to address the concerns of the OP, "Can the driver be trusted?"

Now, I haven't researched this, but I seem to remember reading that the ATI driver(s) had been released to FOSS after nVidia purchased ATI. If that recollection is correct, the OP should be able to get the driver's source code, review it, compile the reviewed copy, and install the driver.

It's not so much about trusting the driver. (I don't know about ATI foss drivers, but I'll look into it, in the meantime for the sake of discussion I'll assume that they are still closed). If there is nothing I can do about trusting the drivers then that's that. But there is something I can do about the installation and possible uninstallation of the drivers. There may be nothing I can do about bugs within the driver, but if there are bugs within the installation script or more importantly in the uninstallation script then if I decide that the driver has to go, I might not be able to uninstall it without leaving a footprint.
Whereas if I could track exactly what the installation did (and if I could keep backups of the files before the changes) then I could guarantee a full backout.
In my job, if I roll out software to production with bugs (that have not been discovered in our extensive testing phase then I have to guarantee that I can backout all changes.
I suppose I was writing out of turn suggesting that I didn't trust the drivers themselves. I don't think I should be forced to trust the installation script for the drivers. This seems unnecessary.
I have thought about using tripwire to monitor all changes, but that suggests a full backup before hand. The other possibility is fakeroot. But this appears to be mainly for packaging software, not installing it.

Well, I haven't actually looked at the ATI install script, since I just grabbed the RPM for the ATI driver when I wanted to use it. (Which I haven't done for several years, since I broke the laptop that used an AIT chip-set.)

But this laptop uses the newer nVidia "on-board" chip-set for which there is no RPM file, so I've been running the install script on all the distributions I have on this system every time the kernel changes. (Which is almost daily for the Jaunty kernel from the Ubuntu development branch.) Anyhow, I've looked at the script -- which is just a bash shell script with a binary "blob" that's loaded into the driver as it's compiled. The point, though, is the the "blob" goes into the driver. The actual installation process is clearly visible in the script, with all the files and actions clearly spelled out.

So, have you looked at the actual script you've got in a standard editor? If it's like the nVidia one, you should have no problem following it, and the only thing you won't see as readable text is the contents of the "blob" which are not executed by the script, but only passed to the compiler for inclusion in the driver so file. (If you're really paranoid you could convert the blob to a binary file and run strings on it, but, since it should be GPU machine code, you're unlikely to see anything meaningful.) Again, the point is that the "blob" goes into the driver and hence into the kernel. Of course malicious code (or even bugs) in the kernel is not desirable, but there may be little you can do about that possibility.

I'll study the script (which I haven't downloaded yet) and see what's what.