Real and effective userids.
Dave Mielke
userid and the effective userid of a process is? When a file is created
its owner is set to the effective userid of the creating process,
whereas when a file is accessed it would appear that the real userid of
the accessing process is used when performing the authorization check.
Conor P. Cahill
The real userid is the id of the person whom is running the program. The
effective userid is the id that is used to determine what the user can
access. However, in order to allow a setuid program to verify that the user
is allowed to perform a specific operation, the access(2) system call
uses the real userid.
For most cases the real userid is equal to the effective user id. running
a setuid program alters the effective user id for the duration of that
process (unless the setuid program sets the effective id back to the real
user id).
--
+-----------------------------------------------------------------------+
| Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 !
| Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 |
+-----------------------------------------------------------------------+
Chris Torek
The `raisin de eatery' (I never could spell in French :-) ) of the real
UID is to allow setuid programs to know who invoked them. It is used
for virtually nothing else.% It is up to setuid programs to do
authorisation tests, preferably by using setreuid() to swap IDs, doing
the operation, and using setreuid() to swap back. (In SysV, where
setreuid() is not available, saved setuid works for everyone but root.)
The rest, obviously, depends on the setuid program.
-----
% access(), setuid(), setreuid(), and getuid() refer to the real uid.
This is not guaranteed to be a complete list.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: ch...@cs.umd.edu Path: uunet!mimsy!chris
Dinh Vu
> userid and the effective userid of a process is?
The real userid is the login id (the id from the passwd file),
and used for communication only. The effective userid is used
for accounting and other stuves...
Dinh
--
Dinh Vu
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!dvu
ARPA: d...@prism.gatech.edu
Conor P. Cahill
> In article <2...@bmers58.UUCP>, da...@bmers58.UUCP (Dave Mielke) writes:
> > Can anyone tell me what the "official" distinction is between the real
> > userid and the effective userid of a process is?
>
> The real userid is the login id (the id from the passwd file),
> and used for communication only. The effective userid is used
> for accounting and other stuves...
The real userid is not the login id. It is the numerical id of "the user"
that is running a process, as opposed to "the effective" id of the process
that is used to determine whether you can open, create, unlink, etc. a file.
The only place where there is a difference between the real and effective
user id's is when the user is running a setuid program that is owned by
another user (or when that setuid program runs a sub-program).
The reason for two id's is to allow the setuid programs to know who
is executing them and to give them the chance to set thier user id
back to the original id after some initial processing is done.
Dave Mielke
>The real userid is the numerical id of "the user"
>that is running a process, as opposed to "the effective" id of the process
>that is used to determine whether you can open, create, unlink, etc. a file.
from within a setuid program it appears to enforce the access rights of
the real userid and not those of the effective userid. Why is this?
Conor P. Cahill
You don't post your program so I can't tell you what is happening, but using
the following code:
main()
{
close(creat("testfile.cpc",0777));
}
compiling the program, changing the mode to 4755,
-rwsr-xr-x 1 cpcahil opadmin 5281 Oct 3 07:20 /tmp/t
log in as user angie with home directory mode:
drwxr-x--- 7 angie opadmin 512 Oct 3 07:23 .
Run /tmp/t and NO file is created since only the owner has write access and the
program runs as cpcahil (who is not the owner).
Run "chmod g+w ." and then re-run /tmp/t and the following file is created
since the user's group does have write access to the current directory:
drwxr-x--- 1 cpcahil opadmin 0 Oct 3 07:24 testfile.cpc
Note that the file is not owned by the current user (angie) but by the owner
of the program that is setuid.
Jeff d'Arcy
> The real userid is the numerical id of "the user"
> that is running a process, as opposed to "the effective" id of the process
> that is used to determine whether you can open, create, unlink, etc. a file.
da...@bmers58.UUCP (Dave Mielke):
> This is intuitively the way things should work, but when I open a file
> from within a setuid program it appears to enforce the access rights of
> the real userid and not those of the effective userid. Why is this?
The system itself will use the EUID for checking permissions, but that
doesn't mean that all programs make it that easy. Some programs quite
deliberately do things such as set the EUID to be the same as the RUID,
effectively undoing the effect of the SUID bit. This is often done to
close a security hole, and thus there's no really good general solution
that doesn't involve serious changes to the semantics of SUID.
Jeff d'Arcy jda...@encore.com (508) 460-0500
Encore has provided the medium, but the message remains my own
Piercarlo Grandi
In article <2...@bmers58.UUCP> da...@bmers58.UUCP (Dave Mielke) writes:
>Can anyone tell me what the "official" distinction is between the real
>userid and the effective userid of a process is? When a file is created
>its owner is set to the effective userid of the creating process,
>whereas when a file is accessed it would appear that the real userid of
>the accessing process is used when performing the authorization check.
The `raisin de eatery' (I never could spell in French :-) ) of the real
UID is to allow setuid programs to know who invoked them. It is used
for virtually nothing else.% It is up to setuid programs to do
authorisation tests, preferably by using setreuid() to swap IDs, doing
the operation, and using setreuid() to swap back. (In SysV, where
setreuid() is not available, saved setuid works for everyone but root.)
The rest, obviously, depends on the setuid program.
-----
% access(), setuid(), setreuid(), and getuid() refer to the real uid.
This is not guaranteed to be a complete list.
Let me be more precise. The difference is that one is used for
accounting, the other for protection.
Suppose that the distinction did not exist; then running a setuid
program would be debited to its author, not its invoker (this would force
every setuid program to do its own accounting, and charging for its use,
which is almost never appropriate).
In other words, a process executes in several "planes" at once (e.g.
accounting, protection, but could also be priority, for example), and
they need not be the same.
An obvious generalization is to have real (accounting) and
effective (protection) owners for files as well. This would solve
some problems with file ownership and accounting for closed
subsystems (notably ingres and the spoolers) that implement their
own protection policies, and thus need to give access to files
only to their own setuid programs, but do not want the space
taken up to be debited to them.
Now many people, especially from Universities, think that
accounting and charging for resources is not important; I have
actually come to the conclusion that is is damn important (even
if it is purely notional) on two grounds:
1) for performance evaluation
2) an elegant charging architecture is a good
corroboration that the overall os architecture is
good.
Let me leave the second point just an hint...
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.abe...@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: p...@cs.aber.ac.uk
Guy Harris
>from within a setuid program it appears to enforce the access rights of
>the real userid and not those of the effective userid. Why is this?
Because either:
1) your UNIX implementation is broken;
2) the program that does the open also calls "access" to check
whether it's really allowed to open the file or not;
3) the program uses "setuid()" or whatever to relinquish its
set-UID privileges before opening the file;
4) your program really isn't running set-UID for some reason;
5) you're misinterpreting what's actually happening.
On non-broken UNIX implementations, the "open" call uses the effective
UID to enforce access rights. Try a trivial set-UID program that prints
the real and effective UIDs, and then just opens a specified file,
reporting success or failure (use "perror" to report failure), and
closes the file, doing nothing else. If *that* acts as if it's using
the real UID to check permissions, and the printout reports that it is,
in fact, set-UID to the UID to which it should be set-UID, 1) is the
most likely cause....
Piercarlo Grandi
An obvious generalization is to have real (accounting) and
effective (protection) owners for files as well. This would solve
some problems with file ownership and accounting for closed
subsystems (notably ingres and the spoolers) that implement their
own protection policies, and thus need to give access to files
only to their own setuid programs, but do not want the space
taken up to be debited to them.
It would also solve the famous chown problem. Currently either chown is
allowed anybody, and then anybody may cheat filespace accounting (by
chowning their files to somebody's else account), or only root (and then
you must write a chown utility that asks for passwords).
If we had "chown -[er]" and user A wanted to let user B acquire
ownership of a file, the following sequence would do the trick with
perfect safety:
user A: chown -e B file
user B: chown -r B file
with a rule that the [er]owner may change the other owner id to itself.
User A has no qualms in making B the eowner, after all it wants to transfer
the actual ownership; user B then may actually acquire the rownership. If
user B does not, user A can always revert the eownership to itself.