[texhax] Explanation? - Was texhash trouble in TL on Ubuntu
ghaverla at materialisations.com
Fri Aug 17 00:56:14 CEST 2012
On August 16, 2012, Axel E. Retif wrote:
> What I do is prepend TeXLive path in /etc/environment:
A bunch of this is of a philosophical nature. Unfortunately, the
people coming into this, have never seen the philosophy.
Root is the superuser, and can do whatever they want to.
Permissions are not checked. Somethings are impossible, so
sometimes root sees errors that look like permissions.
Because root can do anything, people should not get in the habit
of doing anything "normal" as root. Root is there to maintain the
system. Root is not there to run TeX programs, or moreso to run
anything in a GUI. Most *buntu people using sudo are doing so
from a GUI. I can't remember there being any problems, but it is
more likely to have problems from a GUI than from a plain old text
Consequently, the PATH for the root user should be much different
than for ordinary users. A good example is having '.' in the
PATH, this is relatively common for users, it should never be
present in the PATH of root. Users probably have /usr/bin and
/usr/local/bin near the front of the PATH, root should have /bin,
/sbin, /usr/sbin and /usr/local/sbin near the front of the PATH,
and might not even have /usr/bin or /usr/local/bin in the PATH.
Debian, and Debian based systems typically create UserIDs with the
preferred name of the user, and at the same time creating a group
with the same name. This makes UserID _own_ the group of the same
name. And the owner of a group, as an ordinary user, can control
the UserIDs of other logins that belong to that group.
If I am logged in as fred, I am allowed to make wilma a member of
group 'fred'. And I can do the same for barney and betty. And if
mrslate is on the same computer, there is nothing that requires
fred to make mrslate a member of group fred.
Each user is allowed to administer their own group, and they can
make group permissions as permissive or as closed as they want.
They can also make use of SGID on programs, so that anyone in the
group, can run programs as if it was the GROUP running them. Some
people have heard of problems with SUID, SGID is similar, and
missing some of the headaches.
On Debian, the normal installation of PostgreSQL installs a
postgres user. It is not possible to login as the postgres user.
But, there are adminstrative tasks that only the postgres user can
do. The only (proper?) way to do these, is to make use of the
Related to the sudo command, is the su command. Su allows a user
to become another user. With no argument, su assumes someone
wants to become root, and so it prompts for the root password.
But, su will allow users to "become" other users. If fred does
fred is prompted for wilma's password, and if fred knows wilma's
password, fred "assumes" the ID of wilma, and anything fred does
until he closes the shell that su provided, is done as the user
The above is true for all users, except for root. If root wants
to assume any user's ID, no password is asked for. I mentioned
PostgreSQL earlier, and root can "assume" the postgres ID by doing
And no password is required. Which is how the postgres user can
do things, that need to be done manually, when the user postgres
is not allowed to login.
This is too long. I hope this trip into UN*X permissions has been
More information about the texhax