Re: Absolute path in argv[0]

From: Peter T. Breuer (ptb_at_lab.it.uc3m.es)
Date: 10/30/04 

Date: Sat, 30 Oct 2004 16:56:47 +0200

Heny Townsend <henry.townsend@not.here> wrote:
> Floyd L. Davidson wrote:
> > Regardless, the "appropriate" place is certainly not related to
> > the location of the executable.
>
> Much of this thread has become unbecomingly dismissive but the above
> statement takes the cake. Of course the appropriate place is *related*
> to the location of the executable. When I install any piece of freeware,
> for instance, I choose a --prefix value and then all the files are
> installed relative to <prefix>. How, for instance, is
> /opt/samba/lib/smb.conf not related to /opt/samba/sbin/smbd?

Mmmmmmmmmmmmm. Well, I think you are over-endowing the word "related"
here. Of course there is a relation of some kind, in that if the
executable is placed in A, then it is likely that the config file is
placed in B, where A and B share a functional dependence on some hidden
variable (you suggest the --prefix value, forgetting (1) that this is a
compile option in the main, and that (2) there is a separate --sysconf
value that will override or define the placing of the configuration; I
would suggest the variable is more deeply hidden than you!).

As to your example of samba, my smb.conf is in /etc/samba/smb.conf, and
the daemon is in /usr/sbin/smbd. Thus the only installtime --prefix
that could have been used is "/" (since they share no common prefix)
and I would submit that there is therefore "no relation" in the sense
that you require.

The relation that I would say exists is that if I see a daemon in
A = /usr/sbin/foo then I expect its config in B = /etc/foo.conf or
/etc/foo/config, because that is the standard plan. It is what I see in
the case of my smbd. The relation that exists between the two
locations is "has been compiled, installed and configured in the
standard unix way" (no dependence via --prefix).

To illustrate further, the same "unixy" relation also holds for
executables placed in /sbin. The config will still be in /etc. The
config file placement is simply not expected to vary whatever the
placement, in /usr/bin, /usr/sbin, /sbin or /bin. Thus there is "no
relation" between the executable and the conf file placement in the
standard scheme of things. The executable may appear in one of about
four or perhaps six places, and the config file in about two, with "no
relation" to the executable file placement, in the sense that the
variance if it exists is separate and independent. The precise
placements will be up to the distro.

This is the case nowadays even if you personally install in /usr/local -
I woould not generally want to place the config files in /usr/local/etc,
but in /etc, since I expect distro upgrades not to overwrite config
files that have been written or introduced by an administrator (for
safety if you do not trust the distro, you may wish to physically site
them in /usr/local/etc while symlinking from /etc).

> Just to get this out of the way first: I'm a 25-year Unix developer. My
> attitudes are in no way tainted by the Windows way and in fact I'm a
> charter member of the Windows-hater club. One of the things that's so
> noxious about Windows is the focus on the "Personal" part of "Personal
> Computer". In Windows, all installs are local installs. If you have 250
> machines on your network you must install each SW package 250 times,

Uh, yeah. In fairness, RH seem never to have understood the word NFS
properly. Maybe that is changing now that they have turned away from
the workstation to the server market.

> using 250 times as much disk space, make 250 sets of registry entries,
> etc. You never know how much your C:\Windows directory may have been
> polluted by DLL's silently dumped there by an install. And uninstalls
> have historically at least tended to leave cruft behind.
>
> Not to mention that one of the worst things about this model is that in
> many team/workplace environments "personal" thinking is just the wrong
> model. I don't want the compiler to work differently on Tom's machine
> than on ***'s. I don't want to spend half a day debugging a problem

Indeed.

> only to find out it's because the user's machine was pointing at a
> different server from everyone else's. There are such things as teams
> and it follows that there are such things as team conventions, aka
> global settings.

Amen.

> One of the things that's attractive about the Unix model is that
> "installs" can be so simple as to not even require the name. I can
> usually install something on a Unix machine by simply unpacking a tar
> file and modifying PATH and MANPATH to point into the new dir. Or I can

Gag.

> put, say, gcc in /usr/local/gcc[*] and NFS mount it everywhere.
> Uninstalls in this model are as simple as "rm -rf".

Well, you will probably have left some hanging symlinks, if I read you
right!

> [*] Yes, I'm aware that many people and standards have a problem with
> /usr/local. I use it here only because it's the most widely recognized
> example.
>
> Of course it's not possible for every software package to be as easy as
> this but it is *absolutely* a worthwhile goal. And that's all Otto is
> trying to achieve. I don't think he said he wanted to put the config
> file in a bin directory; he wants to *find* the bin directory so as to
> traverse over to a ../etc or equivalent.

I'm still not sure I understand. What's his problem with compiling with

  #define SYSCONFDIR /etc/foo

and letting everything that needs it read SYSCONFDIR/config? If he
wants he can even have

  char sysconfdir[] = stringify(SYSCONFDIR);

and let everything that wants to read strcat(sysconfdir, "config") ?

> Some of the alternatives people are pushing in this thread sound
> perilously close to the Windows way. Consider the problems with putting
> config files in /etc: (1) you have to copy the file to every machine,

Uh, well, that is actually OK. I firmly believe that individual machines
should be allowed to USE the same executables in different
configurations. An example might be a server like heartbeat configured
with a different partner failover on every machine.

So I think the config must be local. If anyone really wants to use a
shared config they can always symlink to it from the local site.

> (2) there's a likelihood of configuration skew, and (3) uninstalls tend
> to leave those lonely files in /etc behind. Just a month or two ago I

There is nothing wrong with leaving files in /etc behind - indeed, it
would always be my aim to do so, ready for the next time I install.

> was burned by an old config file left behind in /etc. Ok, consider the

There is no way to be burned by it - the install would have asked you
what to do with it.

> problems caused by compiling in the path to the config file: (1) it

Nobody is suggesting they compile it in, as much as define a default
value for the position during the compilation. One shoudl be able to
override it via commandline and/or envvar.

> works a heck of a lot better with open source than with commercial
> software and not everyone is doing open source. (2) Even with OSS, it
> makes it hard to package prebuilt binaries (.rpm, .deb, .pkg, etc). Of

I don't see what's hard about it!

> course you can make it overridable with an EV but that just moves the
> local-config burden to ~/.profile.

It's not a burden. Users (and local admins) should be able to override
the default compiled-in position. Anything less would be a kind of
tyranny.

> My own SW tool has the usual chain of config files. I let the user
> specify one as an EV, I look in the cwd, I look in $HOME, I look in
> /etc, and last I try to determine the path to the executable and then go
> up two levels and across to an 'etc' directory and look for a config

Well, I think you should cut out that last bit!

> file there. This allows per-system, per-user, or per-project settings

The "per project" idea has me a bit mystified ... wouldn't everyone in
the project simply define the same env var value?

> but it also provides a global fallback in order to set conventions for
> the entire team, and there's no *need* to ever make a local setting. I

Can you expand on that? I don't quite get it as set out.

> have yet to see an argument, in this thread or the Unix FAQ or
> elsewhere, that convinces me this is stupid. The argument that finding
> the executable is hard, non-portable, and that there are corner cases
> which can't be solved comes the closest but guess what folks, it's still

Well, the real problem is that you and any caller can write anything
you like in argv[0]. Including "yah boo sucks". Thus there is no reason
to trust it for anything more than guesswork, and guesswork is likely
to turn into a security hole ...

> not a deal breaker. For one thing I've been able to find a solution for
> every platform that concerns me. For another, what's the worst thing

Oh - well, yes, I rewrite the argv[] vector too, if that is what you
mean, stepping into the env if necessary for more space, when the area
is contiguous.

> that could happen as the result of some trickster moving the executable
> after it's run but before it locates itself? I wouldn't find the final

It was the basis of a whole load of well-known attacks, but I don't
recall them being around nowadays.

> fallback config file. Boo hoo.

Be careful. I bet Alan Cox still remembers the modus operandi of that
class of atatck!

I think the safest thing to do is use /proc/<þid> in some way, but I
forget just how. One ends up chasing inodes. I recall rewriting
setuidexec (the suid shell interpreter trick - it has to check its
executable to see if the suid bit is set on it) many times every time RH
or somebody closed yet another hole. I don't know if that still works.

> I really think people should get off their high horses here. In
> particular, accusing the other side of being polluted by Windows-think
> is like trying to argue that your presidential candidate has God on his
> side - it could even be true but please stick to verifiable facts.

Peter