open and euid security flaw in 5.0-Current?

Killing killing at
Sat May 17 07:24:38 PDT 2003

Thanks for that Robert will do some more investigation as it does
break screen :(

    Steve /k
----- Original Message -----
From: "Robert Watson" <rwatson at>
To: "Killing" <killing at>
Cc: <freebsd-hackers at>; <freebsd-security at>
Sent: Saturday, May 17, 2003 6:55 AM
Subject: Re: open and euid security flaw in 5.0-Current?

> On Sat, 17 May 2003, Killing wrote:
> > On a FreeBSD 5.0 the behaviour of screen when connecting to other
> > users sessions have changed. Previously:
> > 1. login as userA start a screen as userA and disconnect
> > 2. login as root su - userA "screen -r"
> > 3. result failure as userA cant access the ttyX with such a message
> > Current:
> > 1. login as userA start a screen as userA and disconnect
> > 2. login as root su - userA "screen -r"
> > 3. result failure as userA cant access the ttyX but no message
> >
> > After looking around in screen's code I found that after doing a
> > seteuid( userA ) an open on root's terminal is still succeseding.
> >
> > Surely this is a problem as when running euid userA there should be no
> > access to ruid's files?
> I'm not sure this is the bug (feature?) you think it is.  It sounds like
> you think this might be a mis-evaluation of file permissions more
> generally relating to saved vs. effective vs. real credentials.  Based on
> the fact that other devfs permissions work properly, I actually don't
> think it's that.  What you're seeing is derived from changes in the
> behavior of /dev as a result of devfs in 5.x.  This is a result of
> special-case handling in devfs_access():
>         error = vaccess(vp->v_type, de->de_mode, de->de_uid, de->de_gid,
>             ap->a_mode, ap->a_cred, NULL);
>         if (!error)
>                 return (error);
>         if (error != EACCES)
>                 return (error);
>         /* We do, however, allow access to the controlling terminal */
>         if (!(ap->a_td->td_proc->p_flag & P_CONTROLT))
>                 return (error);
>         if (ap->a_td->td_proc->p_session->s_ttyvp == de->de_vnode)
>                 return (0);
>         return (error);
> It's worth noting, though, that you can accomplish much the same thing by
> opening /dev/tty, which even on RELENG_4, permits you to open your own
> controlling terminal without going through the permission checks on the
> device node for the terminal itself. This reflects the fact that /dev
> entries are not the actual object, just references to an underlying
> object, and access through any of the VFS layer objects is sufficient.
> I'm not entirely sure this is desirable in all cases, but it's apparently
> not specific to FreeBSD.  For example a Linux 2.2 box I have access to
> permits this:
> [rwatson at viking /dev]# su nobody
> bash$ cat /
> bash$ tty
> /dev/pts/0
> bash$ cat /dev/pts/0
> cat: /dev/pts/0: Permission denied
> bash$ cat /dev/tty
> ...
> So does one of Juli's Linux 2.4 boxes.  So our permitting direct access to
> the tty via it's normal name is more liberal than is usual, but the tty
> access via /dev/tty is common across all platforms.  We could easily fix
> the more liberal direct access issue by removing the code, but I'm
> wondering why it's there in the first place.  I've CC'd Poul-Henning Kamp,
> author of our current devfs, to see.
> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert at      Network Associates Laboratories
> _______________________________________________
> freebsd-hackers at mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at"

More information about the freebsd-hackers mailing list