[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Questions and suggestions



Hello everybody! I'm new to this list so please excuse me if these issues 
has already meen discussed.

I've been using MultiTOS for quite some time now, trying to make it 
UNIX-caompatible where ever possible. Now, there are a number of things I 
would like to see in MiNT. Please tell me what the opinion thinks about 
shese things:

1: Shouldn't all process files (in /proc) should have 644, not 600. So
that any user can get full information on them? 

2: A nice thing would be if you could change the mode-bits on the
TOS-filesystem-directories (i.e. u:/c), otherwise, it is impossible to
create a secure system. Since any user cn change, for example, teh
mint.cnf file. I would like to set these directories to 700. 

3: There are a number of system calls that _need_ to be superuser-only.
The most important of these are of course Super() and Supexec(), because
as long as any user can execute this instruction, the system can't be
secure. Other super-only instructions include Dsp_Reset, Dsp_LoadProg,
Jenabit, Setexec and other system calls that can crash the system. 

4: For these things to work, we need a working setuid-flag of course. I
was told that the setuid-flag is not yet implented, it it coming? 

5: A TOSFS is really not necessary. The only thing that is needed is good
interrupt driven devices for the scsi-interface, and the harddisks
(/dev/rhd0 etc...). Then why not use mtools to access DOS-drives?

6: What about implementing a SysV-style sticky-bit on directories? On 
SysV, when the sticky bit is set on a directory, you can't delete files 
in it even if you have write permission on the directory. You must have 
write permission to the file itself also.

7: I would really love to see a good virtual memory manager integrated 
with MiNT.

8: Should a line be terminated by LF or CR/LF? Personally I don't like
CR/LF. A good example is the lf-flag (in stty). There is no way that I 
can disable lf->cr/lf mapping because mintlib outputs the cr itself! And 
it's difficult to open stdout/stderr in binary mode.

9: There should be some kind of history for Setexec so that killing a 
process which changes the vbl-routine does not crash when killed.

10: I think that a disk should be mounted as root (u:/), or at least 
nothing should exist in this directory (apart from, of course, /proc, 
/dev, /pipe and /shm). The mounted drives at boot time could be specified 
in mint.cnf.

What is the general opinion about these suggestions? Are any of them 
already considered? And if rejected, why?

-- 
Elias M}rtenson                         !  No joke here.
elias@proxxi.uf.se                      !  Sorry for the inconvenience.
C-programmerare och GNU-fanatiker       !