2.6.8.1-mm1 Tty problems?

DISCUSSION ismail dönmez 7 participants 26 messages Aug 17, 2004 – Aug 26, 2004 2 messages not in the archive

lore

Share & tools

lore

ismail dönmez

author

2004-08-17 14:10 UTC #0 lore raw

Hi all,

Watch this sequence :

cartman@southpark:~$ echo "foo" > foo
cartman@southpark:~$ cat foo
foo
cartman@southpark:~$ less foo
cartman@southpark:~$

As you see less doesn't show up anything. Strace shows this piece of info :

<snip>

open("/dev/tty", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffff430) = -1 ENOTTY (Inappropriate ioctl for device)

</snip>

Any ideas whats going on?

P.S : 2.6.8 was working just fine.

Signature · 1 line

Time is what you make of it

Paul Fulghum

2004-08-17 18:08 UTC #1 lore raw

Quoted 14 lines · ismail dönmez

cartman@southpark:~$ echo "foo" > foo
cartman@southpark:~$ cat foo
foo
cartman@southpark:~$ less foo
cartman@southpark:~$ 
As you see less doesn't show up anything. Strace shows this piece of info :
<snip>
open("/dev/tty", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffff430) = -1 ENOTTY (Inappropriate ioctl for device)

Quoted 5 lines

</snip>
Any ideas whats going on?
P.S : 2.6.8 was working just fine.

Since this involves the controlling tty, try backing out selinux-revalidate-access-to-controlling-tty.patch (available in the broken-out mm patches)

--
Paul Fulghum
[email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

ismail dönmez

author

2004-08-17 19:01 UTC #4 lore raw

Quoted 4 lines · Paul Fulghum

Even if a feature is not be enabled,
backing out a patch can verify it does not
touch code outside of the feature.

Indeed backing up selinux-revalidate-access-to-controlling-tty.patch fixed "less" problem. But some other problems remain and the real issue is /dev/tty is a directory now! :

cartman@southpark:~$ ls -al /dev/tty
total 0
drwxr-xr-x   2 root root     0 2004-08-18 00:52 ./
drwxr-xr-x  15 root root     0 2004-08-17 21:53 ../
crw-------   1 root root 3, 10 2004-08-18 00:52 s
crw-------   1 root root 3,  0 2004-08-18 00:52 s0
crw-------   1 root root 3,  1 2004-08-18 00:52 s1
crw-------   1 root root 3,  2 2004-08-18 00:52 s2
crw-------   1 root root 3,  3 2004-08-18 00:52 s3
crw-------   1 root root 3,  4 2004-08-18 00:52 s4
crw-------   1 root root 3,  5 2004-08-18 00:52 s5
crw-------   1 root root 3,  6 2004-08-18 00:52 s6
crw-------   1 root root 3,  7 2004-08-18 00:52 s7
crw-------   1 root root 3,  8 2004-08-18 00:52 s8
crw-------   1 root root 3,  9 2004-08-18 00:52 s9

And this breaks many applications. Any idea why /dev/tty is a directory now?

Cheers,
ismail

Signature · 1 line

Time is what you make of it

Paul Fulghum

2004-08-17 19:34 UTC #5 lore raw

Quoted 21 lines · ismail dönmez

But some other problems remain and the real
issue is /dev/tty is a directory now! :

cartman@southpark:~$ ls -al /dev/tty
total 0
drwxr-xr-x   2 root root     0 2004-08-18 00:52 ./
drwxr-xr-x  15 root root     0 2004-08-17 21:53 ../
crw-------   1 root root 3, 10 2004-08-18 00:52 s
crw-------   1 root root 3,  0 2004-08-18 00:52 s0
crw-------   1 root root 3,  1 2004-08-18 00:52 s1
crw-------   1 root root 3,  2 2004-08-18 00:52 s2
crw-------   1 root root 3,  3 2004-08-18 00:52 s3
crw-------   1 root root 3,  4 2004-08-18 00:52 s4
crw-------   1 root root 3,  5 2004-08-18 00:52 s5
crw-------   1 root root 3,  6 2004-08-18 00:52 s6
crw-------   1 root root 3,  7 2004-08-18 00:52 s7
crw-------   1 root root 3,  8 2004-08-18 00:52 s8
crw-------   1 root root 3,  9 2004-08-18 00:52 s9

Quoted 1 line

And this breaks many applications. Any idea why /dev/tty is a directory now?

That does not look right.
Char dev 3 is the pty major.
This could be left over from running with the controlling-tty patch.

Try recreating /dev/tty as a char special file:
mknod -m 666 /dev/tty c 5 0

--
Paul Fulghum
[email protected]

ismail dönmez

author

2004-08-17 19:37 UTC #6 lore raw

Quoted 4 lines · Paul Fulghum

Try recreating /dev/tty as a char special file:
mknod -m 666 /dev/tty c 5 0

Yes totally works!

Cheers,
ismail

Signature · 1 line

Time is what you make of

ismail dönmez

author

2004-08-17 19:45 UTC #7 lore raw

In reply to Paul Fulghum

Quoted 6 lines

That does not look right.
Char dev 3 is the pty major.
This could be left over from running with the controlling-tty patch.
Try recreating /dev/tty as a char special file:
mknod -m 666 /dev/tty c 5 0

Hmm I use udev and /dev/tty dir is created again at startup. So something else is broken too I think.

Cheers,
ismail

Signature · 1 line

Time is what you make of it

Paul Fulghum

2004-08-17 20:07 UTC #8 lore raw

Quoted 10 lines · ismail dönmez

Quoted 6 lines
That does not look right.
Char dev 3 is the pty major.
This could be left over from running with the controlling-tty patch.
Try recreating /dev/tty as a char special file:
mknod -m 666 /dev/tty c 5 0
Hmm I use udev and /dev/tty dir is created again at startup. So something else is broken too I think.

This is almost certainly related to the addition of pty devices to devfs in bk-driver-core.patch Change is by [email protected]

This explains why you are seein pty major devices created in a /dev/tty directory.

Specifically the changes in drivers/char/tty_io.c in function tty_register_device()

Try backing out that specific portion of bk-driver-core.patch

--
Paul Fulghum
[email protected]

ismail dönmez

author

2004-08-17 20:52 UTC #9 lore raw

CC'ing Andrew too.

Quoted 11 lines · Paul Fulghum

This is almost certainly related to the addition of pty devices to devfs in bk-driver-core.patch Change is by [email protected]
This explains why you are seein pty major devices created in a /dev/tty directory.
Specifically the changes in drivers/char/tty_io.c in function tty_register_device()
Try backing out that specific portion of bk-driver-core.patch

Backed out whole bk-driver-core.patch and everything works as expected. Thanks for help.

Cheers,
ismail

Signature · 1 line

Time is what you make of it

Olaf Hering

2004-08-18 06:24 UTC #10 lore raw

In reply to Paul Fulghum

Quoted 13 lines · Paul Fulghum

Quoted 10 lines · ismail dönmez
Quoted 6 lines
That does not look right.
Char dev 3 is the pty major.
This could be left over from running with the controlling-tty patch.
Try recreating /dev/tty as a char special file:
mknod -m 666 /dev/tty c 5 0
Hmm I use udev and /dev/tty dir is created again at startup. So something else is broken too I think.

Quoted 6 lines

This is almost certainly related to the addition of pty devices to devfs in bk-driver-core.patch Change is by [email protected]
This explains why you are seein pty major devices created in a /dev/tty directory.

/dev/tty is supposed to be char c 5 0, /class/tty/tty/dev will tell udev how to create it, see man 4 tty.
No idea who came up with the bright idea to put legacy bsd devices in a subdir. Documentation/devices.txt shows that my patch is ok, it handles up to 256 device nodes.
If you are using udev, file a bugreport for your distros package. In the meantime, remove the offending line from your udev.rules file.

Signature · 3 lines

USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

ismail dönmez

author

2004-08-18 06:34 UTC #11 lore raw

Quoted 7 lines · Olaf Hering

/dev/tty is supposed to be char c 5 0, /class/tty/tty/dev will tell udev how to create it, see man 4 tty.
No idea who came up with the bright idea to put legacy bsd devices in a subdir. Documentation/devices.txt shows that my patch is ok, it handles up to 256 device nodes.
If you are using udev, file a bugreport for your distros package. In the meantime, remove the offending line from your udev.rules file.

I don't think you understood me. /dev/tty is created as a char device in 2.6.8.1 kernel. So I am sure udev is fine but it shows up as a directory in 2.6.8.1-mm1 kernel and if I backup bk-driver-core.patch its all normal again.

Cheers,
ismail

Signature · 1 line

Time is what you make of it

Olaf Hering

2004-08-18 06:42 UTC #12 lore raw

Quoted 9 lines · ismail dönmez

Quoted 7 lines · Olaf Hering
/dev/tty is supposed to be char c 5 0, /class/tty/tty/dev will tell udev how to create it, see man 4 tty.
No idea who came up with the bright idea to put legacy bsd devices in a subdir. Documentation/devices.txt shows that my patch is ok, it handles up to 256 device nodes.
If you are using udev, file a bugreport for your distros package. In the meantime, remove the offending line from your udev.rules file.

Quoted 4 lines

I don't think you understood me. /dev/tty is created as a char device in 2.6.8.1 kernel. So I am sure udev is fine but it shows up as a directory in 2.6.8.1-mm1 kernel and if I backup bk-driver-core.patch its all normal again.

Works fine here.
Check you udev.rules file if some rule matches the pattern ptyp0.

Signature · 3 lines

USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Martin Schlemmer

2004-08-18 18:55 UTC #13 lore raw

Quoted 11 lines · Olaf Hering

Quoted 9 lines · ismail dönmez
Quoted 7 lines · Olaf Hering
/dev/tty is supposed to be char c 5 0, /class/tty/tty/dev will tell udev how to create it, see man 4 tty.
No idea who came up with the bright idea to put legacy bsd devices in a subdir. Documentation/devices.txt shows that my patch is ok, it handles up to 256 device nodes.
If you are using udev, file a bugreport for your distros package. In the meantime, remove the offending line from your udev.rules file.

Quoted 7 lines

Quoted 4 lines
I don't think you understood me. /dev/tty is created as a char device in 2.6.8.1 kernel. So I am sure udev is fine but it shows up as a directory in 2.6.8.1-mm1 kernel and if I backup bk-driver-core.patch its all normal again.
Works fine here.
Check you udev.rules file if some rule matches the pattern ptyp0.

Hmm, Ok, so I see we have pty devices in there as well. Ismail, what tries to use /dev/tty anyhow?

Signature · 1 line

Martin Schlemmer

Tonnerre

2004-08-19 17:29 UTC #14 lore raw

Saut,

Quoted 1 line · Martin Schlemmer

Ismail, what tries to use /dev/tty anyhow?

It's the standard UN*X way of finding your controlling TTY: open /dev/tty and do an isatty on it. So I'd suppose around 90% of the console software does that.

Tonnerre

Martin Schlemmer

2004-08-19 19:26 UTC #15 lore raw

Quoted 9 lines · Tonnerre

Saut,
Quoted 1 line · Martin Schlemmer
Ismail, what tries to use /dev/tty anyhow?
It's the standard UN*X way of finding your controlling TTY: open /dev/tty and do an isatty on it. So I'd suppose around 90% of the console software does that.

Yes sorry, I was on drugs.

Greg, below patch should be in order.

---

etc/udev/rules.d/50-udev.rules 2004-08-19 21:22:48.804245520 +0200 renamed from etc/udev/rules.d/50-udev.rules.orig 2004-08-19 21:17:08.947911536 +0200 +1 -1

@@ -65,7 +65,7 @@
 
 # pty devices
 KERNEL="pty[p-za-e][0-9a-f]*", NAME="pty/m%n", SYMLINK="%k"
-KERNEL="tty[p-za-e][0-9a-f]*", NAME="tty/s%n", SYMLINK="%k"
+KERNEL="tty[p-za-e][0-9a-f]*", NAME="pty/s%n", SYMLINK="%k"
 
 # ramdisk devices
 KERNEL="ram[0-9]*", NAME="rd/%n", SYMLINK="%k"

---

Signature · 1 line

Martin Schlemmer

Olaf Hering

2004-08-19 19:26 UTC #16 lore raw

etc/udev/rules.d/50-udev.rules 2004-08-19 21:22:48.804245520 +0200 line 68

Quoted 11 lines · Martin Schlemmer

Greg, below patch should be in order.
---
etc/udev/rules.d/50-udev.rules 2004-08-19 21:22:48.804245520 +0200 renamed from etc/udev/rules.d/50-udev.rules.orig 2004-08-19 21:17:08.947911536 +0200 +1 -1
@@ -65,7 +65,7 @@
 
 # pty devices
 KERNEL="pty[p-za-e][0-9a-f]*", NAME="pty/m%n", SYMLINK="%k"
-KERNEL="tty[p-za-e][0-9a-f]*", NAME="tty/s%n", SYMLINK="%k"
+KERNEL="tty[p-za-e][0-9a-f]*", NAME="pty/s%n", SYMLINK="%k"

Dont forget to update Documentation/devices.txt

Signature · 3 lines

USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Martin Schlemmer

2004-08-19 19:42 UTC #17 lore raw

Quoted 9 lines · Olaf Hering

Quoted 7 lines · Martin Schlemmer
Greg, below patch should be in order.
---
etc/udev/rules.d/50-udev.rules 2004-08-19 21:22:48.804245520 +0200 renamed from etc/udev/rules.d/50-udev.rules.orig 2004-08-19 21:17:08.947911536 +0200 +0 -0
@@ -65,7 +65,7 @@
 

Quoted 6 lines

etc/udev/rules.d/50-udev.rules 2004-08-19 21:22:48.804245520 +0200 line 68
Quoted 4 lines
etc/udev/rules.d/50-udev.rules 2004-08-19 21:22:48.804245520 +0200 renamed from etc/udev/rules.d/50-udev.rules.orig 2004-08-19 21:17:08.947911536 +0200 +1 -1
 # pty devices
 KERNEL="pty[p-za-e][0-9a-f]*", NAME="pty/m%n", SYMLINK="%k"
-KERNEL="tty[p-za-e][0-9a-f]*", NAME="tty/s%n", SYMLINK="%k"
+KERNEL="tty[p-za-e][0-9a-f]*", NAME="pty/s%n", SYMLINK="%k"
Dont forget to update Documentation/devices.txt

Its part of the udev 'devfs compat' ruleset, so not what would have been created standard. I checked the code again and devfs use /dev/pty/s# and not /dev/tty/s#, so it somewhere that either I or one of the others made a boo-boo that did the original of that rule file ...

Signature · 1 line

Martin Schlemmer

Martin Schlemmer

2004-08-17 21:27 UTC #18 lore raw

In reply to ismail dönmez

Quoted 10 lines · ismail dönmez

Quoted 6 lines
That does not look right.
Char dev 3 is the pty major.
This could be left over from running with the controlling-tty patch.
Try recreating /dev/tty as a char special file:
mknod -m 666 /dev/tty c 5 0
Hmm I use udev and /dev/tty dir is created again at startup. So something else is broken too I think.

Just fix the permissions in /etc/udev/permissions.d/50-udev.permissions, and file a bug with your distribution if its not self-compiled.

Signature · 1 line

Martin Schlemmer

Paul Fulghum

2004-08-17 21:18 UTC #19 lore raw

In reply to ismail dönmez

Quoted 30 lines · ismail dönmez

Quoted 4 lines · Paul Fulghum
Even if a feature is not be enabled,
backing out a patch can verify it does not
touch code outside of the feature.
Indeed backing up selinux-revalidate-access-to-controlling-tty.patch fixed "less" problem. But some other problems remain and the real issue is /dev/tty is a directory now! :
cartman@southpark:~$ ls -al /dev/tty
total 0
drwxr-xr-x   2 root root     0 2004-08-18 00:52 ./
drwxr-xr-x  15 root root     0 2004-08-17 21:53 ../
crw-------   1 root root 3, 10 2004-08-18 00:52 s
crw-------   1 root root 3,  0 2004-08-18 00:52 s0
crw-------   1 root root 3,  1 2004-08-18 00:52 s1
crw-------   1 root root 3,  2 2004-08-18 00:52 s2
crw-------   1 root root 3,  3 2004-08-18 00:52 s3
crw-------   1 root root 3,  4 2004-08-18 00:52 s4
crw-------   1 root root 3,  5 2004-08-18 00:52 s5
crw-------   1 root root 3,  6 2004-08-18 00:52 s6
crw-------   1 root root 3,  7 2004-08-18 00:52 s7
crw-------   1 root root 3,  8 2004-08-18 00:52 s8
crw-------   1 root root 3,  9 2004-08-18 00:52 s9

Quoted 1 line

And this breaks many applications. Any idea why /dev/tty is a directory now?

Olaf, Greg:

The addition of pty devices to sysfs in bk-driver-core.patch of 2.6.8.1-mm1 seems to be causing the problem described above. See the rest of this thread for more details.

--
Paul Fulghum
[email protected]

Martin Schlemmer

2004-08-17 21:32 UTC #20 lore raw

Quoted 32 lines · Paul Fulghum

Quoted 30 lines · ismail dönmez
Quoted 4 lines · Paul Fulghum
Even if a feature is not be enabled,
backing out a patch can verify it does not
touch code outside of the feature.
Indeed backing up selinux-revalidate-access-to-controlling-tty.patch fixed "less" problem. But some other problems remain and the real issue is /dev/tty is a directory now! :
cartman@southpark:~$ ls -al /dev/tty
total 0
drwxr-xr-x   2 root root     0 2004-08-18 00:52 ./
drwxr-xr-x  15 root root     0 2004-08-17 21:53 ../
crw-------   1 root root 3, 10 2004-08-18 00:52 s
crw-------   1 root root 3,  0 2004-08-18 00:52 s0
crw-------   1 root root 3,  1 2004-08-18 00:52 s1
crw-------   1 root root 3,  2 2004-08-18 00:52 s2
crw-------   1 root root 3,  3 2004-08-18 00:52 s3
crw-------   1 root root 3,  4 2004-08-18 00:52 s4
crw-------   1 root root 3,  5 2004-08-18 00:52 s5
crw-------   1 root root 3,  6 2004-08-18 00:52 s6
crw-------   1 root root 3,  7 2004-08-18 00:52 s7
crw-------   1 root root 3,  8 2004-08-18 00:52 s8
crw-------   1 root root 3,  9 2004-08-18 00:52 s9

Quoted 8 lines

Quoted 1 line
And this breaks many applications. Any idea why /dev/tty is a directory now?
Olaf, Greg:
The addition of pty devices to sysfs in bk-driver-core.patch of 2.6.8.1-mm1 seems to be causing the problem described above. See the rest of this thread for more details.

He has the wrong permissions in /etc/udev/permissions.d/50-udev.permissions (or whatever), or no entry for it, and his default_mode (in /etc/udev/udev.conf) is very restrictive, or he does not use pam_console (or using it with a display manager?), or add some other explanation. Personally I would just say that he/his_distribution should fix the shipped udev.permissions.

Apart from above, I cannot say anything is wrong with the addition of tty's to sysfs, and if its the same in functionality as the old patch from Greg, then I ran it for months no problem.

Signature · 1 line

Martin Schlemmer

ismail dönmez

author

2004-08-18 05:44 UTC #21 lore raw

On Tue, 17 Aug 2004 23:36:02 +0200, Martin Schlemmer <[email protected]>

Quoted 7 lines

He has the wrong permissions in /etc/udev/permissions.d/50-udev.permissions (or whatever), or no entry for it, and his default_mode (in /etc/udev/udev.conf) is very restrictive, or he does not use pam_console (or using it with a display manager?), or add some other explanation. Personally I would just say that he/his_distribution should fix the shipped udev.permissions.

I run Slackware 10 and got this in /etc/udev/permissions.d/udev.permissions :

# console devices
console:root:tty:0600
tty:root:tty:0666
tty[0-9][0-9]*:root:tty:0660
vc/[0-9]*:root:tty:0660

But the real problem is not permissions but the fact that /dev/tty is a directory now not a character device. Is this intended? If yes this will break many userspace applications which will assume /dev/tty is a character device. Greg can you please comment?

Cheers,
ismail

Signature · 1 line

Time is what you make of it

Martin Schlemmer

2004-08-18 18:40 UTC #22 lore raw

Quoted 18 lines · ismail dönmez

On Tue, 17 Aug 2004 23:36:02 +0200, Martin Schlemmer <[email protected]>
Quoted 7 lines
He has the wrong permissions in /etc/udev/permissions.d/50-udev.permissions (or whatever), or no entry for it, and his default_mode (in /etc/udev/udev.conf) is very restrictive, or he does not use pam_console (or using it with a display manager?), or add some other explanation. Personally I would just say that he/his_distribution should fix the shipped udev.permissions.
I run Slackware 10 and got this in /etc/udev/permissions.d/udev.permissions :
# console devices
console:root:tty:0600
tty:root:tty:0666
tty[0-9][0-9]*:root:tty:0660
vc/[0-9]*:root:tty:0660

Quoted 5 lines

But the real problem is not permissions but the fact that /dev/tty is a directory now not a character device. Is this intended? If yes this will break many userspace applications which will assume /dev/tty is a character device. Greg can you please comment?

---

# ls -l /dev/tty
crw-rw-rw-  1 root tty 5, 0 Aug 16 20:25 /dev/tty
---

I think its something else - most likely a rule in /etc/udev/rules.d/50-udev.rules ? Could you post that (or /etc/udev/rules.conf or whatever file is applicable) ?

Signature · 1 line

Martin Schlemmer

Greg KH

2004-08-26 23:09 UTC #23 lore raw

In reply to ismail dönmez

Quoted 18 lines · ismail d?nmez

On Tue, 17 Aug 2004 23:36:02 +0200, Martin Schlemmer <[email protected]>
Quoted 7 lines
He has the wrong permissions in /etc/udev/permissions.d/50-udev.permissions (or whatever), or no entry for it, and his default_mode (in /etc/udev/udev.conf) is very restrictive, or he does not use pam_console (or using it with a display manager?), or add some other explanation. Personally I would just say that he/his_distribution should fix the shipped udev.permissions.
I run Slackware 10 and got this in /etc/udev/permissions.d/udev.permissions :
# console devices
console:root:tty:0600
tty:root:tty:0666
tty[0-9][0-9]*:root:tty:0660
vc/[0-9]*:root:tty:0660

Quoted 4 lines

But the real problem is not permissions but the fact that /dev/tty is a directory now not a character device. Is this intended? If yes this will break many userspace applications which will assume /dev/tty is a character device. Greg can you please comment?

/dev/tty is a char device on my system. Perhaps your rules files are making that not happen properly.

thanks,

greg k-h

Paul Fulghum

2004-08-17 21:19 UTC #24 lore raw

In reply to ismail dönmez

Quoted 19 lines · ismail dönmez

Hi all,
Watch this sequence :
cartman@southpark:~$ echo "foo" > foo
cartman@southpark:~$ cat foo
foo
cartman@southpark:~$ less foo
cartman@southpark:~$ 
As you see less doesn't show up anything. Strace shows this piece of info :
<snip>
open("/dev/tty", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffff430) = -1 ENOTTY (Inappropriate ioctl for device)

Quoted 5 lines

</snip>
Any ideas whats going on?
P.S : 2.6.8 was working just fine.

Stephen, James, Andrew:

the selinux-revalidate-access-to-controlling-tty patch seems to be causing the problem with less program as shown above. See the rest of this thread for more details.

--
Paul Fulghum
[email protected]

Stephen Smalley

2004-08-18 12:29 UTC #25 lore raw

Quoted 5 lines · Paul Fulghum

Stephen, James, Andrew:
the selinux-revalidate-access-to-controlling-tty patch seems to be causing the problem with less program as shown above. See the rest of this thread for more details.

I find that puzzling, given that flush_unauthorized_files is only called if the process is changing SIDs on exec, and running less certainly doesn't involve a SID transition (at least for any policy that I have seen). I tried the sequence shown with 2.6.8.1-mm1 with SELinux enabled and disabled, and did not see the behavior he describes. Is the bug reproducible? Was he running with SELinux enabled or disabled? What policy did he have loaded?

Signature · 2 lines

Stephen Smalley <[email protected]>
National Security Agency

Paul Fulghum

2004-08-18 13:11 UTC #26 lore raw

Quoted 7 lines · Stephen Smalley

I find that puzzling, given that flush_unauthorized_files is only called if the process is changing SIDs on exec, and running less certainly doesn't involve a SID transition (at least for any policy that I have seen). I tried the sequence shown with 2.6.8.1-mm1 with SELinux enabled and disabled, and did not see the behavior he describes. Is the bug reproducible? Was he running with SELinux enabled or disabled? What policy did he have loaded?

According to Ismail:
* The problem is reproducible.
* SELinux is disabled.
* With the patch the problem occurs.
* With the patch reversed, the problem went away.

Unfortunately, this appears to be mixed up with another 2.6.8.1-mm1 change causing udev to garble the creation of /dev/tty and pty devices.

Applying/reversing the controlling-tty patch in isolation creates/corrects the symptom with the less program, so there seems to be some relation.

--
Paul Fulghum
[email protected]

ismail dönmez

author

2004-08-18 13:27 UTC #27 lore raw

Quoted 19 lines · Paul Fulghum

Quoted 7 lines · Stephen Smalley
I find that puzzling, given that flush_unauthorized_files is only called if the process is changing SIDs on exec, and running less certainly doesn't involve a SID transition (at least for any policy that I have seen). I tried the sequence shown with 2.6.8.1-mm1 with SELinux enabled and disabled, and did not see the behavior he describes. Is the bug reproducible? Was he running with SELinux enabled or disabled? What policy did he have loaded?
According to Ismail:
* The problem is reproducible.
* SELinux is disabled.
* With the patch the problem occurs.
* With the patch reversed, the problem went away.
Unfortunately, this appears to be mixed up with another 2.6.8.1-mm1 change causing udev to garble the creation of /dev/tty and pty devices.

Quoted 8 lines

Applying/reversing the controlling-tty patch in isolation creates/corrects the symptom with the less program, so there seems to be some relation.
--
Paul Fulghum
[email protected]

The problem ended up as a problem in Slackware's default udev.rules file. Now I'm running vanilla -mm1 and everything works. Thank you all for your attention!

Cheers,
ismail

Signature · 1 line

Time is what you make of it