[OS X TeX] Authentication, prvileges, users

[Gerben Wierda]

Let me add to this to make it more clear:

(Welcome to Unix)

When you log in as yourself (not as 'root' or 'System Administrator') 
you do not have System Administrator priviliges, even if  this is an 
account that is allowed to do System Administration (like the first 
account created on an OS X machine). Any normal account that may do 
System Administration does not have the privileges, but it can *acquire* 
them. This is why you have to enter a password when you change system 
settings, use Installer, etc. But as long as you have not been asked for 
that password, you are just an ordinary user.

On Mac OS X (unix) there are 'users' and 'groups'. The System 
Administrator is user 'root'. All the ordinary accounts that are allowed 
to do System Administration work are member of the group 'wheel'. 
Members of the group wheel, may (temporary) be granted 'root' 
privileges. This is what happens when you enter your password on an 
authentication panel. It is even true that the system at the time that 
you acquire these privileges remembers who you really are (unless the 
software instructs the system to forget about that).

Suppose you are logged in as gerben. In a Terminal window you can go to 
directory /usr/local and see what the permissions are:

% cd /usr/local
% ls -al
total 0
drwxr-xr-x  18 root    wheel  1024 May 15 11:23 .
drwxr-xr-x  10 root    wheel  1024 May 15 20:28 ..
drwxr-xr-x  35 root  wheel  1146 Jan 24 10:47 bin
drwxr-xr-x   3 root  wheel   264 Oct 27  2001 lib
drwxr-xr-x   4 root  wheel   264 Apr 27 04:32 man
drwxr-xr-x  18 root  admin   568 May 10 17:12 teTeX
etc.

You are currently user gerben and you belong to several groups, amongst 
others 'wheel'. The characters above say that /usr/local is owned by 
user root and group wheel. It says: drwxr-xr-x. That means
	d 	= it is a directory
Then follow three sets of three characters. First for the owner, than 
for group members and then for everybody else.
The user set is "rwx", which means that the owner root may read, write 
and execute.
The group set is "r-x", which means that the members of group wheel may 
read and execute, but not write
The rest set is "r-x" as well, which means that everybody else may read 
and execute, but not write

As long as you are gerben.wheel, you cannot write. When you 
authenticate, you become root.wheel and you may write.

To complicate things, some tools check not against your authenticated 
status, but stubbornly use your 'real' identity. To illustrate, I enter 
the following commands here (sudo is used to authenticate as root, it 
will ask for a Password which remains valid for a few minutes):
1. I run the 'whoami' command, it tells me I am gerben
2. I run the 'whoami' command authenticated as root through the sudo 
command, it tells me I am root
3. I run the 'who' command with the arguments "am i", it tells me I am 
gerben
4. I run the 'who' command authenticated as root through the sudo 
command with the arguments "am i", it tells me I am gerben

[dumbledore:/usr] gerben% whoami
gerben
[dumbledore:/usr] gerben% sudo whoami
Password:
root
[dumbledore:/usr] gerben% who am i
gerben   ttyp4    May 16 09:06
[dumbledore:/usr] gerben% sudo who am i
gerben   ttyp4    May 16 09:06

Which means that 'whoami' tells me what my 'effective' identity is, 
which has changed after authentication. But the 'who' command tells me 
what my 'real' identity is, which does not change. So you can imagine 
what happens with several commands when it is not clear what identity is 
used. The weirdest things may happen when your 'effective' identity and 
your 'real' identity differ. I have had several problems, both with 
TeXGSInstaller and i-Installer. For instance, when running as 'effective 
identity' root but 'real identity' gerben, Cocoa would use 'root' as the 
basis for file permissions and ownership but it would use 'gerben' as 
the basis for file locations, resulting in root-owned files in gerben's 
~/Library directory which were then unusable by gerben. In fact, most of 
Cocoa is not 'setuid-safe'. When you run with effective identity root 
and real identity, Cocoa will for instance report that you may not write 
a certain file that is writable by root but not by ordinary users. This 
is in fact not true, because when you actually try to write the file, 
you will succeed.

The behaviour of most programs and functions are pretty well set, so you 
know normally what you're getting in to, but it is not always very 
logical which identity is used and it differs for many tools. this is 
why my installers set the real identity equal to the effective identity 
when they do things authenticated, that minimizes the possible confusion 
and conflicts.

G

On Thursday, May 16, 2002, at 12:57 , Gerben Wierda wrote:

> On Thursday, May 16, 2002, at 08:15 , Bruno Voisin wrote:
>
>> Hello Gerben,
>>
>> I attempted to install the first two i-Packages (using "Open URL...") 
>> and got the following error messages:
>>
>> ### bzip2.pre_install: Cannot write in directories 
>> /usr/local/{bin,lib,include,man/man1}. Bailing out...
>> Task terminated with status 1
>>
>> ### libpng.pre_install: Cannot write in directories 
>> /usr/local/{bin,lib,include}. Bailing out...
>> Task terminated with status 1
>>
>
> You are supposed to have write access in those directories. I you have 
> not, you need to install the package as someone who has (e.g. System 
> Administrator). You can do that by either logging in as root (if you 
> have that account enabled) or use Pseudo.app to start i-Installer. Or 
> you can make sure that you have write access in /usr/local, for 
> instance by modifying it so that you have write access  for the group.
>
> The packages itself do not require authentication, but they do need 
> write access in /usr/local or subdirectories thereof.
>
> As long as Apple does not upgrade it's Security Framework I am caught 
> in a difficult position. If I use the framework to enable people to 
> authenticate at will, I lose the possibility to interact with the 
> installation process (e.g. aborting it). I also lose the possibility to 
> handle normal output and error messages separately. Hence the 
> 'authenticating dedicated installers' which let you authenticate and 
> replace themselves with an authenticated copy. It is ugly and not the 
> best solution, security policy wise (you could accidentally leave an 
> app running with admin privileges), but I need fixes to the Security 
> Framework before I can do it 'right'.
>
> Gerben
>
>
> -----------------------------------------------------------------
> To UNSUBSCRIBE, send email to <info at email.esm.psu.edu> with
> "unsubscribe macosx-tex" (no quotes) in the body.
> For additional HELP, send email to <info at email.esm.psu.edu> with
> "help" (no quotes) in the body.
> -----------------------------------------------------------------
>


-----------------------------------------------------------------
To UNSUBSCRIBE, send email to <info at email.esm.psu.edu> with
"unsubscribe macosx-tex" (no quotes) in the body.
For additional HELP, send email to <info at email.esm.psu.edu> with
"help" (no quotes) in the body.
-----------------------------------------------------------------