Messages in this thread |  | | From | ulmo@q ... | Subject | Re: Bugs, Problems and Questions | Date | 07 Sep 1996 20:18:25 -0400 |
| |
Wolfram Kleff <kleff@athene.informatik.uni-bonn.de> writes:
> I have some questions/problems regarding the Linux Kernel: > (verified with Linux Kernel 2.0.18) > > 1) In /proc/mounts the root filesystem device is called "rootfs" > but in ../src/linux/Documentation/devices.txt it is called: > "/dev/root root device symbolic Current root filesystem" > so why don't we call it "/dev/root" instead of "rootfs" ? > (I have patched the kernel: works ok)
Similar here, although a bit different:
Q:~$ cat /proc/mounts rootfs / ext2 rw 0 0 /dev/hda2 /usr ext2 rw 0 0 none /proc proc rw 0 0 /dev/hdc /cdrom iso9660 ro 0 0 Q:~$ cat /etc/mtab /dev/hdb3 / ext2 rw 1 1 /dev/hda2 /usr ext2 rw 1 1 none /proc proc rw 0 0 /dev/hdc /cdrom iso9660 ro 0 0 Q:~$
I thought /proc/mounts is supposed to be the replacement to /etc/mtab?
In any case this means the utilities that use /etc/mtab should be updated to allow for "rootfs" in case someone sticks /proc/mounts into the "which file is mtab?" #define.
> 2) A security problem: The "setterm -reset" escape seqence doesn't clean > the console history-scrollback buffer ! > The Problem: A logged out console user leaves his "footprints" > in the history-scrollback buffer which is a vulnerability in > a multiuser environment. > There should be a escape sequence like "setterm -reset" that > cleans the history-scrollback buffer without using "ways-around".
Try this:
Q:~$ disalloc 1 disalloc: VT 1 is the console can cannot be disallocated Q:~$ disalloc 3 Q:~$ disalloc 99 VT_DISALLOCATE: No such device or address disalloc: could not disallocate console 99 Q:~$ disalloc 64 VT_DISALLOCATE: No such device or address disalloc: could not disallocate console 64 Q:~$ disalloc 63 Q:~$ disalloc 0 disalloc: 0: illegal VT number Q:~$
(Wait; I thought there were 64 of them?? What happened to #64?? An off-by-one error? Ok found it in /usr/src/linux/include/linux/tty.h: #define MAX_NR_CONSOLES 63 /* serial lines start at 64 */ #define MAX_NR_USER_CONSOLES 63 /* must be root to allocate above this */ /* Note: the ioctl VT_GETSTATE does not work for consoles 16 and higher (since it returns a short) */ Is the Note: still correct? Hmm, looks like it -- time to fix that for 2.1?)
Also, I don't use VT 1 for anything; X (via xdm) is in 2 (I was trying to figure out a simple way to get it to come up in 1), and I have a getty sitting out at 9 in case xdm/X gets unruly (such as in my previous SHIFT-SCROLL_LOCK reports). Why can't I do it to #1??
vc_disallocate() doesn't check for #1. Who does? Aha:
/* * Disallocate memory associated to VT (but leave VT1) */ case VT_DISALLOCATE: if (arg > MAX_NR_CONSOLES) return -ENXIO; if (arg == 0) { /* disallocate all unused consoles, but leave 0 */ for (i=1; i<MAX_NR_CONSOLES; i++) if (! VT_BUSY(i)) vc_disallocate(i); } else { /* disallocate a single console, if possible */ arg--; if (VT_BUSY(arg)) return -EBUSY; if (arg) /* leave 0 */ vc_disallocate(arg); } return 0;
Well, then, Q:~$ disalloc 0 disalloc: 0: illegal VT number Q:~$ must be in the user program disalloc; disalloc ought to allow 0 for all unused terminals as in the ioctl. Which package is disalloc? (my hybrid self / Slackware 3.0.0 / RedHat 3.0.3/Rembrandt/devel / Debian system doesn't make it obvious :\)
> 6) Real bug: "cp /proc/kcore /...." can hold ("freeze") the kernel > e.g. with X started. Not even a klog bug report is delivered. > Ok, never do nasty things with the superuser, but there should be a > few "savety belts" around/in the kernel memory get routine.
This was discussed recently by someone else. Your suggestion that safety belts be added is the only new thing. They noted that /proc/kcore includes device addresses (as it logically should).
|  |