On Fri, 2006-12-08 at 18:49 -0600, Michael C Thompson wrote:
> Stephen Smalley wrote:
> > On Thu, 2006-12-07 at 18:15 -0500, Linda Knippers wrote:
> >> I was having intermittent problems with the 'more' command and finally
> >> had a chance to identify the problem.
> >>
> >> The symptom is that 'more' will abort after one screen full, getting
> >> an EBADF when it tries to read the user input. It doesn't matter if
> >> the system is in permissive mode. The issue is that 'more' is reading
> >> stderr. That's not a problem until one runs 'newrole', which is
> >> paranoid about stdout and stderr, reopening them as WRONLY.
> >>
> >> I filed a bugzilla on the problem.
> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218880
> >>
> >> Do we change 'more'? I wonder what else will stop working with the
> >> current 'newrole' behavior.
> >
> > I think we revert newrole to its prior behavior (it used to open all
> > three descriptors rw, but that was "cleaned up").
>
> So I'm not sure why more would be reading stderr, that doesn't make
> sense at all to me. Assuming this is unreasonable, we shouldn't be
> changing newrole, but fixing more.
I created a trivial test program that tried to read and write each of
descriptors 0-2, and ran it from the shell, and it encountered no
errors. So applications may have come to depend on such behavior, and
we don't want newrole to break compatibility unless there is some
security rationale for doing so. Only scenario there is if we would
ever want the newrole'd shell to be able to inherit stdin (i.e. read)
but not {stdout, stderr} (i.e. write) or vice versa. They all refer to
the same object here (the tty, re-opened by newrole itself).
Remember as well that we not only have to consider applications included
in the distro itself but also third party applications, both open source
and otherwise.
> Also, at what point did this "clean up" take place? Because (admittedly
> I almost never use more), I don't ever recall this being an issue.
I think that the change from O_RDWR on all three descriptors to O_RDONLY
for stdin and O_WRONLY for stdout and stderr happened during a cleanup
by Steve Grubb almost a year ago in preparation for his patches to add
audit support to newrole (which was the first change to require newrole
to be suid). At the time, I believe I mentioned compatibility as a
possible concern, but couldn't remember a specific example of breakage.
--
Stephen Smalley
National Security Agency
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp