Re: /dev/full a security hole?

H. Peter Anvin (
9 Sep 1997 22:55:00 GMT

Followup to: <>
By author: Darin Johnson <>
In newsgroup:
> > Consider the code:
> >
> > /* Use memory for whatever reason */
> >
> > setuid(getuid()); /* Drop permissions */
> >
> > buffer = malloc(BUFSIZ);
> > fd = open(userfile, O_RDONLY);
> > n = read(fd, buffer, BUFSIZ);
> > write(1, buffer, n);
> > close(fd);
> >
> > This kind of code is very common (although it is simplified here.)
> > Doesn't have to be a FILE buffer, and it gives you a cozy peephole
> > into the privileged portion of the program.
> Huh, I'm still baffled here. Just by changing uid, you don't suddenly
> lose the privilege of reading your own memory. You don't need to
> exploit a bug to read your own memory. Or am I misunderstanding
> the bug? It was said:

Yes you are. Remember that one of the most common ways of subverting
Unix systems is by making setuid programs and daemons do things they
were not intended to do. Here we're making a safe setuid program
unsafe because we've changed the meaning of read() from underneath it.

> The "setuid(getuid())" baffles me as well. If you had the extra
> privilege, you could have just exploited that fact without changing
> resetting the uid... And there is no such thing, really, as a
> "privileged portion of the program", either the whole program is
> setuid, or none of it is.

Bogus! It is *very* common for setuid programs to drop permissions in
order to access the filesystem or perform another operation (such as
exec()) as an unprivileged user. In this case, the hazard comes from
the "access the filesystem as an unprivileged user" operation.


    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See for web page and full PGP public key
Always looking for a few good BOsFH.  **  Linux - the OS of global cooperation
        I am Baha'i -- ask me about it or see