what actually happens under the hood when I type ./configure, make and make install?
 

I know it would check environment variables and stuff like enable/disable options but does it write to a configuration file in the folder afterwards? and if so, if I run ./configure again, would the configuration file be overwritten?

as for make I know it would compile if the configuration is done without errors but what if there was an error in the configuration process? Usually it gives me some kind of error message like target not found, but would the compilation process be carried out halfway or would it not be carried out at all?

all that make install does is copy the appropriate files into the appropriate directory?

config.log would typically be the configure log, and yes, it should be overwritten on subsequent runs of configure.

There will often be some object files (*.o) and such already created, so if you get this far before noticing a problem, it's a good idea to do "make clean" before continuing.

Not necessarily, but ideally, yes. You can look at the actual "install" target in the Makefile to see exactly what it does; this will often require you to "work backwards" through some other targets perhaps, but that's not too difficult :)

One particular example of an app whose Makefile doesn't just "copy ... files into the appropriate director[ies]" is apcupsd. It attempts to patch the /etc/rc.d/rc.6 script and also installs /etc/rc.d/rc.apcupsd outside the package directory (DESTDIR); it's apps like this that make it a good idea to always test the whole process as a normal user before doing anything as root.

how would I do that ? with a prefix to /tmp and then checkng the output ?

Something like this:

Then inspect the contents of /tmp/testing-appname. This is a great way to find out whether manpages need to be compressed (they usually do), whether --mandir needed to be explicitly defined, what config files to rename to *.new and handle in doinst.sh, whether to update the shared mime info, desktop database, etcetera, and so on...

Of course, if you encounter an error in the "make install" above, then you know that something's trying to write to a location it's not allowed to write, or some other operation is trying to happen that you can't do as a normal user. Sometimes this is minor - for example, the install target might try to explicitly set ownership of the installed files with something like this:
If this is the only thing causing a problem, then you'll be fine to go ahead and do the build as root. However, you might have to patch that out of the Makefile temporarily to verify that nothing else undesirable is going on.

Hey Robby,

I'm hijacking the thread slightly, but I think this is still on-topic:

How would I go about really learning what's desirable or not? There's got to be some guidelines on which permissions are appropriate in which circumstances, but I'll be darned if I can figure them out on my own.

For instance, there seems to be a lot of heartburn among people making packages when a packages uses setuid to give root permissions to regular users for some tasks. But sometimes that's a good thing, right? So how does one learn to tell good practice from bad?

Regards,

-Drew

The configure script generates a log of everything that it checks and the results of these checks. That log file is helpful if the configuration fails, but not so much otherwise. The really important files that configure creates are the Makefiles. The Makefiles have the build recipes specific for your machine.

If the configuration fails, there will be no Makefiles generated and, thus, no target when you issue the make command. However, successful configuration doesn't guarantee a successful compilation and link. For example, configure might check that you have libfoo, but not the version. You may have a version of libfoo that is too old or too new and the compilation/linking will then fail.

It does a little more than that. It will create directories if needed, it will update the dynamic library database, it will set permissions on files/directories, etc. But, essentially it just copies files although it should use install rather than cp.

I really like to see how slackers are familiar with ./configure make && make install because of 'rolling their own' and slackbuilds.
Sometimes people forget that when you type: apt-get foo, emerge foo, pacman -S foo, rpm -i foo, make install clean foo, pkg_add -r foo, installpkg foo, etc, etc. Somebody has done the ./configure make, etc. read the REAME and INSTALL for you.
The other thing i like is the 'purity' you are allowed to retain in your build scripts instead of relying on functions and package manager customizations.
Interesting thread. I'll keep and eye on it.

Well, I wish there were an easy answer to that.

Let's look at slackins as an example application: http://slackbuilds.org/repository/12.0/system/slackins/

This is essentially a gui frontend to pkgtool(8) and friends, so it simply MUST have root privileges in order to be useful.

Therefore, you can install it with with uid=root, gid=root, mode=0755 ("normal" ownership and permissions for binaries), and then you'll have to be root when you execute in order to do anything with it. Doing it this way will mean that lots of people will resort to doing something insecure with X in order to run a gui app as root inside the context of a user session.

Alternatively, you can choose to install it suid with uid=root, gid=wheel, mode=4750 (yes, that's redundant - 4xxx means suid). This will elicit screaming from some about "OMG!!!111 INSECURE - SUID!!!111" *but* they should generally shut up. We've already considered the alternative, so let's look at the practical implications of this. Yes, it is suid, but only members of the 'wheel' group can even execute it. Even *if* someone undesirable is in the 'wheel' group, they *still* have to enter the root password in order to do anything with slackins.

Long story short, installing this one suid and only executable by members of a specified group (in this case, 'wheel' was the obvious choice) is actually *more* secure than the alternative.

Ultimately, I guess that doesn't answer your question, but that's because I'm not sure *how* to answer it. It's basically a matter of "look at the big picture" and decide what the *best* option is within the context of the application's purpose, usage patterns, etcetera...

Maybe I misunderstood something but why this is wrong:

or just:

I'm not saying there's anything necessarily *wrong* or *bad* with doing either - I'm simply saying that lots of people won't do it correctly. That being said, yes, I know I'm not exactly a poster boy for "let's protect people from their own stupidity," but I have my moments... :-)

As an aside, either of those means more work...

Btw, why doesn't xhost +root work? According to manual it should, but I am getting an error smth similar to root is not a hostname.


P.S. Third or fourth time when I'm getting angry at Linux (hdparm, wall thing and ctrl+d were very irritating). I can't understand why it is so hard to write proper documentation (even worms has a manual). The funniest thing is when I get a suggestion in man smth to read complete manual running info smth, but there is no info smth or it is the same as man smth. Any help for such issues is very appreciated.

Hmmm... Good question.

It would be better to use xauth instead of xhost if you want to enable root access to your X display. See my Wiki example:
http://alien.slackbook.org/dokuwiki/...=sudo#x_and_su
Alternatively, Slackware supports which will let you run X applications as root without further configuration; the downside is that you won't get /sbin:/usr/sbin:/usr/local/sbin into your PATH.

Eric