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

[Valdis.Kletnieks at vt.edu]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20060526/f35e50f7/attachment.sig>