> 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).