Hello

> * I then argue that in the current world, autocompletion is not
> reliable, because since it does not stat(), it cannot hide filenames
> the user cannot execute, such as a 0644 file. What your autocompletion
> is currently printing is an approximation of the programs you can run,
> not an accurate list - in other words, merging /bin and /sbin would not
> "break" autocompletion, because it is already "broken". You are just
> not seeing it because the (good) convention of not putting anything
> non-executable in /bin is widely followed - but the whole mechanism
> is simply relying on a convention, and stricto sensu you should not
> entirely trust it.

So ultimately everything in the computer world is just a convention.
It is just convention that stat() gives you real filesystem permissions -
strictly speaking you should first check the kernel source, that nobody
has broken that, and then the hardware underneath that too.

But snark aside, maybe view that these things are just conventions
allows you to argue that they should be changed easily, while my position
is that many things (like the shell) do rely on them being that way, and
then won't work (or work as well) if they are changed. If they are
called conventions, rules or laws doesn't make that much difference.

> >* You have say a setgid executable which probably isn't perfectly
> > secure. You trust your admin crowd to run it, but maybe not
> > a php script which has escaped apache.
> >
> >* So you put it into /usr/sbin and do
> >
> > chmod 750 /usr/sbin
> > chgrp admin /usr/sbin
> >
> >* And now if an exploit for said setgid tool becomes available
> > then the php script won't be able to run it.
>
> OK, thanks for clarifying. This isn't security through obscurity
> indeed. However, you could achieve the exact same result by putting
> this tool in /usr/bin - or anywhere else - with chown root:admin
> and chmod 2750 - you don't need a separate directory to hold binaries
> you only want a specific group to run.

No, sorry. Doing chown root:admin && chmod 2750 does not give anybody
in the admin group (the ones who should be allowed to run it) any
extra rights - they are already running with admin group privileges -
setgid would be used to grant controlled access to another group
(like disk, dialout, mail, etc, etc).

So I think I understand your desire to clean things up, rationalise
them - but the thing is that everybody uses a classical unix
system in a slightly different way - a feature that is considered
antiquated by some is essential to others, so these structures should
change slowly and in a backward compatible manner.

There are lots of examples of that, eg vim is a superset of vi,
and in vim you can still drop down to ex mode which is the
successor to ed. Maybe to use a sentimental analogy: A city
with layers of history is much more rich/interesting and often
more liveable than somewhere which has been bulldozed flat and
centrally planned by a funky architect. In this regard systemd
is so irritating since it demolishes so much established code
to be replaced with something which I think is likely to spald
and leak in a few years time :)

regards

marc