Really wierd 'more' interaction with 'newrole' and stderr...

OK.. .running Rawhide as of this morning, strict policy in permissive
mode - so selinux *shouldn't* kill anything off.

I start off as a user, and then 'su' to root. I'm running with:

# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=valdis:staff_r:staff_t
# ls -lZ `tty`
crw-------  valdis valdis valdis:object_r:staff_devpts_t   /dev/pts/0

If I do 'more /etc/passwd /etc/group', it works fine (any two files is OK,
or any single file over 1 screen long).

Then I 'newrole -r sysadm_r'..

#  id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=valdis:sysadm_r:sysadm_t
# ls -lZ `tty`
crw-------  valdis valdis valdis:object_r:sysadm_devpts_t  /dev/pts/0

Now if I try to 'more' anything that's more than one screen, it just silently
exits after the first screen/file/etc.

Some poking with strace indicates that when it fails, we have this:

getcwd("/home/valdis", 4098)            = 13
write(1, "\33[7m--More--(Next file: /etc/gro"..., 40)) = 40
read(2, 0xbfa266c7, 1)                  = -1 EBADF (Bad file descriptor)
ioctl(2, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0)         
        = 4
exit_group(0)                           = ?

while the working case has:

getcwd("/home/valdis", 4098)            = 13
write(1, "\33[7m--More--(Next file: /etc/gro"..., 40)) = 40
read(2, "\n", 1)                        = 1

The problem is in newrole.c, where we do this:

  fd = open(ttyn,O_WRONLY);

to open fd2. Now, should this be fixed to O_RDWR, or should 'more'
be fixed to read off stdin rather than stderr?

[Stephen Smalley]

On Fri, 2006-05-26 at 13:17 -0400, Valdis.Kletnieks(a)vt.edu wrote:
>  OK.. .running Rawhide as of this morning, strict policy in
> permissive
>  mode - so selinux *shouldn't* kill anything off.
>  
>  I start off as a user, and then 'su' to root. I'm running with:
>  
>  # id
>  uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
> context=valdis:staff_r:staff_t
>  # ls -lZ `tty`
>  crw-------  valdis valdis valdis:object_r:staff_devpts_t   /dev/pts/0
>  
>  If I do 'more /etc/passwd /etc/group', it works fine (any two files is OK,
>  or any single file over 1 screen long).
>  
>  Then I 'newrole -r sysadm_r'..
>  
>  #  id
>  uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
> context=valdis:sysadm_r:sysadm_t
>  # ls -lZ `tty`
>  crw-------  valdis valdis valdis:object_r:sysadm_devpts_t  /dev/pts/0
>  
>  Now if I try to 'more' anything that's more than one screen, it just
> silently
>  exits after the first screen/file/etc.
>  
>  Some poking with strace indicates that when it fails, we have this:
>  
>  getcwd("/home/valdis", 4098)            = 13
>  write(1, "\33[7m--More--(Next file: /etc/gro"..., 40)) = 40
>  read(2, 0xbfa266c7, 1)                  = -1 EBADF (Bad file descriptor)
>  ioctl(2, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0
>  ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0)        
>          = 4
>  exit_group(0)                           = ?
>  
>  while the working case has:
>  
>  getcwd("/home/valdis", 4098)            = 13
>  write(1, "\33[7m--More--(Next file: /etc/gro"..., 40)) = 40
>  read(2, "\n", 1)                        = 1
>  
>  The problem is in newrole.c, where we do this:
>  
>    fd = open(ttyn,O_WRONLY);
>  
>  to open fd2. Now, should this be fixed to O_RDWR, or should 'more'
>  be fixed to read off stdin rather than stderr? 
Hmm...they used to be O_RDWR, but Steve Grubb submitted a patch that
changed them a while back as part of a general cleanup of newrole.  If
programs expect stdout and stderr to be rw, then I suppose newrole needs
to open them that way, although it does seem odd to read from your error
stream.

-- 
Stephen Smalley
National Security Agency

On Fri, 26 May 2006 13:27:56 EDT, Stephen Smalley said:

>  Hmm...they used to be O_RDWR, but Steve Grubb submitted a patch that
>  changed them a while back as part of a general cleanup of newrole.  If
>  programs expect stdout and stderr to be rw, then I suppose newrole needs
>  to open them that way, although it does seem odd to read from your error
>  stream. 
It can't read from stdin, because that might be in use:

grep foo bar* | more

And most shells open stderr as R/W, so reading from that works.

One can certainly argue that stderr *should* be write-only, and programs
using stderr for reading should probably be fixed to open /dev/tty and use
that instead.  But not knowing whether it's just this one odd program,
or lots of them, I can't really say.

I suppose Fedora could just do the equivalent change in /bin/bash and see
how many bug reports come in. :)

[Michael Sweet]

Valdis.Kletnieks(a)vt.edu wrote:
>  On Fri, 26 May 2006 13:27:56 EDT, Stephen Smalley said:
>  
> > Hmm...they used to be O_RDWR, but Steve Grubb submitted a patch that
> > changed them a while back as part of a general cleanup of newrole.  If
> > programs expect stdout and stderr to be rw, then I suppose newrole needs
> > to open them that way, although it does seem odd to read from your error
> > stream.
>  
>  It can't read from stdin, because that might be in use:
>  
>  grep foo bar* | more
>  
>  And most shells open stderr as R/W, so reading from that works.
>  
>  One can certainly argue that stderr *should* be write-only, and programs
>  using stderr for reading should probably be fixed to open /dev/tty and use
>  that instead.  But not knowing whether it's just this one odd program,
>  or lots of them, I can't really say.
>  ... 
But don't programs like "more" open /dev/tty?

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com

On Fri, 26 May 2006 13:53:47 EDT, Michael Sweet said:

>  But don't programs like "more" open /dev/tty? 
What 'more' uses:

int readch () {
        unsigned char c;

        errno = 0;
        if (read (fileno(stderr), &c, 1) <= 0) {
                if (errno != EINTR)
                        end_it(0);
                else
                        c = otty.c_cc[VKILL];
        }
        return (c);
}

There's only one reference to /dev/tty, and it's re-opening stdin
to /dev/tty when spawning a 'vi'.