Linux-Development-Sys Digest #143, Volume #7 Thu, 2 Sep 99 14:14:38 EDT
Contents:
The conceptual sandbox? (James Andrews)
Re: gdb Reference (David T. Blake)
Re: Question: Child Process I/O (Grant Edwards)
Re: TAO: the ultimate OS (void)
Re: LINUX AND COREL ([EMAIL PROTECTED])
Re: affs freezes kernel 2.2.11 ([EMAIL PROTECTED])
Kernel message dupfd: fd 1040, max 1024 (Ulrich Eckhardt)
Re: set up c++ development environment (Johan Kullstam)
Re: IDE for c++ dev? (Johan Kullstam)
Re: PCI card question (Johan Kullstam)
----------------------------------------------------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: The conceptual sandbox?
Date: Thu, 02 Sep 1999 13:55:44 +0000
"Vladimir Z. Nuri" wrote:
>
> there are different ways to define "virus"..
> 1. a program that when run, does damage the OS
> 2. a program that can potentially damage the OS when run
>
> now, clearly, (1) seems to require a solution to the
> halting problem, i.e. knowing what a program will do
> before it does it so to speak. a theoretical impossibility.
>
> but for (2) it is quite possible to create programs that are fully
> functional yet have no potential to disrupt the OS.
>
> so by changing the definition of what a virus is slightly, we could
> theoretically create a virus-proof OS.
Hmm, I dont think you can change the definition of a virus, that seems a
little absurd. Since technically, the virus is a seperate autonomous
unit to the operating system, it is the extraneous factor, the actions
of which you cannot control. Therefor the only available option to
avoid potential damage to a running system is to "vet" the functions of
the machine.
A lot of people on this thread truly don't seem to understand the
concept properly. Too many people seem to think that the flaws of one
badly written example define the limitations of the concept. This is,
to quote a typical Glaswegian phrase, baws.
The conceptually ideal sandbox, as a component of an operating system,
is actually a simple idea. In this eventuality, the sandbox acts as the
"quarantine process", it monitors each call to operating system
functions and tests for reasonable bounds, if these are exceeded then
the user is asked to make a decision about the fate of the exceptional
task. This way the routes a virus may commonly use to infiltrate your
system are covered. If a running thread attempts to alter the contents
of a startup script, the sandbox environment halts it, and asks the user
if they wish to confirm the action. When ever any request is made, with
the potential to harm the equilibrium achieved, the system can either
make a judgement call (for more obvious exceptions, such as recursive
deletions, attempts to write file sizes over 10 Meg). More sensible
software could be designed to request such priveledges before just
violating its rights, thus making a smooth environment
The major weapon on the side of the operating system is that it is
always guaranteed to be running first, and it should always control the
environment of the task. With modern memory management systems, tasks
can be limited to access only within their own data space. Using this
tool, we can limit a task to only access devices through OUR
interfaces. Once the task leaves its own space and enters our drivers,
the original programmer has no control, they have to respect the
operating systems ability to perform the requested operation. At this
point, the request can be type-tested, to ensure no foul intentions.
With a new operating system, where functionality can be incorporated at
the lowest conceivable level, every aspect of the system can be
sandboxed, without much effort.
This sandboxing method is in itself a solution to the halting problem as
each running process must request each operation, and these requests can
be examined for a halting situation, and denied where applicable. In
this respect, most operating systems already contain the framework to
implement full sandboxing, but because it was not incorporated from the
start, they would now require far too much work. This is a simple
progression from the memory protection, user and file segregation of
current OS's.
The only disadvantage of this methodology is that it assumes the low
level functions of the implementing OS are perfect, but then, don't we
all aim for that anyway? We cant assume we write flawless software, but
its not an impossibility. In fact, stability of an operating system
could be improved greatly by simple modularisation. Ensuring a very
small simple object performs all of its methods flawlessly isnt actually
that difficult. If the smallest components are flawless, the objects
relying on those become slightly easier to debug.
At the end of the day, I don't understand how so many people can sit and
deny such a simple concept. As for all of the "but then you'd have to
stop the process doing anything" comments, what the hell are you talking
about? If you decide to paint one room of your house, does it
automatically imply that you must paint the entire house? The piece of
the puzzle you seem to be missing is the concept of event boundaries.
When a request is made for something simple, say a file, you can check
this file to see whether it falls within reasonable bounds. If it is a
core file, imperative to the operation of the system, and a users
process is requesting write access, you refuse. If its a file outside
of the users usual file areas, but still within their allowable space
you ask for confirmation, to ensure its not a run away program. If it
is within the local space of the user, automatically allow the access.
This is a simple example, the beauty of computers is their ability to
perform mathematical, and logical tasks at ludicrous speeds. It wouldnt
be very difficult to create an environemt with much more defined
boundaries, or more "intelligent" judgement. It also wouldnt be
difficult to make a far more confined sandbox for the first run of a new
piece of software. Allow read access to some files, simulated write
access (merely uses a temporary directory rather than the actual files
requested, that way, no overwriting can occur, and resultant files can
be tested to ensure the software does what it was meant to) and access
to fake components of the system (fake username, etc, some critical
files could have sandbox shadows to hide their content from prying
programmers). It could have its GUI limited to a reasonable volume of
components with great ease, to ensure it doesnt try to spam your screen,
attempts to invoke other processes could be monitored and intercepted
with ease, so no software automatically mailing the authors, at least
not with out asking permission first.
As you can see, the sandbox idea is far from limited. Many of the
people discussing on this thread seem to have a fixed image of a sandbox
drawn from a substandard implementation, but the concept has far more
scope than that discussed here, and it is a relatively simple concept.
Most current OS's couldnt implement one properly, because they are far
too large, clunky and heterogeneous. They use a mash of languages and
interfaces, and allow far too much unmonitored access. However, the
best way to create such a system, is to embed it in a new operating
system, from the ground up. This way you control each and every
component, and can ensure that the sandbox protocols are implemented
from the very lowest levels.
Well, thats enough post for about 3 weeks, so I'll leave it at that,
James
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: gdb Reference
Date: 2 Sep 1999 13:30:55 GMT
Reply-To: [EMAIL PROTECTED]
Peter Samuelson <[EMAIL PROTECTED]> wrote:
> [David T. Blake <[EMAIL PROTECTED]>]
> > The man page references the book and the info pages.
>
> So *that*'s where the book is mentioned.
>
> > Info format kinda lacks friendly tools to view it with compared to a
> > hard back book.
>
> You don't consider tex, dvips and lpr to be friendly tools?
> Note that I originally said .texi, not .info.
Well, they are all well and good if you have TeX loaded.
I do, but quite a few people don't load TeX. It is a very
large set of programs to view documentation. I kinda prefer
using man and less, a few much smaller programs. Unfortunately,
GNU often doesn't give me that option.
BTW, I would use xdvi (and not kdvi or dvips) as a viewer. The
linux version has hyperlink capabilities built in, which will be
used for dvi viewing of .texi format pages.
Dvips would require that you print the documentation, which is
an odd suggestion for online documentation. That also requires a
printer. So, for actually learning about gdb, you need a TeX
package like tetex (80 mbytes), and a printer at hand. Or a book.
I'd probably stoop to use something bloated like emacs and info
first, since it seems to have the best search capabilities of any
info browser.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: grant@nowhere. (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Question: Child Process I/O
Date: Tue, 31 Aug 1999 14:26:50 GMT
In article <7qg421$1pg$[EMAIL PROTECTED]>, Peter Samuelson wrote:
>[Herng-Jeng Jou <[EMAIL PROTECTED]>]
>> In the parent process, how do I determine when the child process has
>> done its number crunching and is waiting for further input? Should I
>> use /proc?
>
>Don't bother trying. Just send it input as fast as you can, and let
>the kernel block you when it's tired of buffering you.
Or, if you want get a little more fancy, you can use a
bi-directional connection (two pipes, actually) so that you can
read responses from the child process: write() a command, then
read() the response. The read() will block until the child
replies. Or you can use select() or some other scheme to wait.
That way you not only know it's done, you can get status/error
information back.
I've got a bit of code somewhere that I often use to run a
child process with its stdin, stdout, and stderr connected to
pipes so that the parent can write to the child's stdin and
read its stdout and stderr. It's a very handy trick -- you can
do things like spawn a copy of gnuplot if your program needs to
generate a plot, run a bunch of text through sed, whatever.
It's pretty small, so I'll include it in this post even though
this isn't a source group...
>> How do I determine whether there is still something in the output
>> buffer?
>
>Not easy. I still don't understand why you need to do this.
I'm not even sure what the question means. What "output buffer"?
==============================cut here==============================
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>
#include <signal.h>
#include <errno.h>
#if 0
extern int errno, sys_nerr;
#endif
#define errorString() (((errno)<sys_nerr)?sys_errlist[errno]:"unknown error")
/*---------------------------------------------------------------------------
* Run a program in a child process with child's stdin, stdout, and stderr
* connected to pipes.
*
* Parameters:
* wfd: pointer to int where you want to store the fd that is
* connected to the child's stdin
* rfd: pointer to int where you want to store the fd that is
* connected to the child's stdout
* refd: pointer to int where you want to store the fd that is
* connected to the child's stderr
* path: path of executable
* argv: address of array of char pointers for child's argv. Use NULL to
* terminate list
*
* Returns:
* Child's PID, 0 on error
*
* Rememter:
* write() to *wfd, read() from *rfd and *refd
*
*/
int runProgramAsSlave(int *wfd, int *rfd, int *refd, char *path, char *argv[])
{
int masterToSlaveStdin[2];
int slaveStdoutToMaster[2];
int slaveStderrToMaster[2];
char *slaveArgv[1] = {NULL};
char **slaveArgvPtr = slaveArgv;
int pid;
if (argv)
slaveArgvPtr = argv;
if (pipe(masterToSlaveStdin) ||
pipe(slaveStdoutToMaster) ||
pipe(slaveStderrToMaster))
{
perror("pipe");
return 0;
}
pid = fork();
if (pid == 0)
{
/* child process */
int errorfd;
FILE *errorStream;
/* I don't know why, but things work alot better if this process
* ignores the tstp signal (ctrl-Z).
*
* If not, it locks up if you hit ctrl-Z then "bg" the program.
*/
signal(SIGTSTP,SIG_IGN);
if ((errorfd = dup(fileno(stderr))) < 0)
{
perror("dup");
exit(1);
}
fcntl(errorfd, F_SETFD, 1);
errorStream = fdopen(errorfd,"w");
if (errorStream == NULL)
{
perror("fdopen");
exit(1);
}
if ((dup2(masterToSlaveStdin[0], fileno(stdin)) < 0) ||
(dup2(slaveStdoutToMaster[1], fileno(stdout)) < 0) ||
(dup2(slaveStderrToMaster[1], fileno(stderr)) < 0))
{
fprintf(errorStream,"dup2 failed: %s\n",errorString());
exit(1);
}
close(slaveStdoutToMaster[0]);
close(slaveStderrToMaster[0]);
close(masterToSlaveStdin[1]);
execv(path,slaveArgvPtr);
fprintf(errorStream,"execv %s failed: %s\n",path,errorString());
exit(1);
}
if (rfd) *rfd = slaveStdoutToMaster[0];
if (refd) *refd = slaveStderrToMaster[0];
if (wfd) *wfd = masterToSlaveStdin[1];
return pid;
}
==============================cut here==============================
--
Grant Edwards grante Yow! "DARK SHADOWS"
at is on!! Hey, I think
visi.com the VAMPIRE forgot his
UMBRELLA!!
------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 2 Sep 1999 16:03:23 GMT
On 2 Sep 1999 15:42:09 GMT, Peter da Silva <[EMAIL PROTECTED]> wrote:
>In article <7ql4r9$[EMAIL PROTECTED]>,
>Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>
>> I submit that a truly good OS & application environment would
>> not pit the experienced against the inexperienced, anyway.
>
>The Amiga was pretty good at that, given the resources they had to work
>with, and NeXT allegedly did a reasonably good job, though I haven't had
>much opportunity to play with it.
My experience with NeXTStep was that my users, who were almost entirely
ignorant of the inner workings of computers, had little difficulty
getting around, especially once I showed them a couple of tricks.
I administered the systems like plain old BSD systems, except that I had
to pick up some NetInfo chops as I went along.
So I would say that NeXT did a good job of making the system usable for
experienced and inexperienced users alike, which is one of the reasons I
am looking forward to the release of MacOS X Client.
I wonder if they're keeping NetInfo at all.
--
Ben
[X] YES! I'm a brain-damaged lemur on crack, and I'd like to
order your software package for $459.95!
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.misc
Subject: Re: LINUX AND COREL
Date: 02 Sep 1999 10:20:09 -0400
J Mars <[EMAIL PROTECTED]> writes:
>
> There are talks that Corel will bring out a Linux Wordperfect suite and
> O/S. Did anyone tried this?.
Will be available early 2000...according to their web site www.corel.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: affs freezes kernel 2.2.11
Date: Thu, 02 Sep 1999 15:43:05 GMT
Hi!
My 2.0.36 kernel mounted my Amiga-hd with no problems the first time,
but when I moved back to the Amiga, the Amiga couldn't detect the
ffs-partitions on the drive at all!!
I did not umount the drive when I shut down the PC, I just took a
shutdown -hn now. I took the drive back to the PC, and then I just got
an error message telling that there is a bad superblock on drive
/dev/hdb1 (maybe you're trying to mount an extended partition inside??)
So, I'm not sure how safe it is to mount the Amiga-HD in Linux yet ..
but maybe the AFFS support is better in 2.2.11?
//ZnowbaLL [EMAIL PROTECTED]
In article <9Ptu3.1199$[EMAIL PROTECTED]>,
root <[EMAIL PROTECTED]> wrote:
> Has anyone had any luck mounting an Amiga ffs disk with any Linux
> kernel? While I was picking goodies in the 2.2.11 kernel to enable, I
> decided to try adding affs, since I have a couple of Amiga formatted
> zip and syquest disks I'd like to access. Whether I use affs as a
> module or directly compiled in, as soon as I try
> mount -t affs /dev/sdb1 /mnt/azip
> I get something like
> RDSK sd(blur)(blur)(blur)
> with the first blur apparently being letters a through o, and the
> other blurs being digits 0-1 and 0-9. Since my Advansys SCSI
> controller works fine with VFAT, DOS, HFS, and the usual EXT2 disks,
> I can't imagine that this nonsense is. What's expecially vexing is
> that it locks the system up so hard, I have to hit the HW reset.
>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Ulrich Eckhardt <[EMAIL PROTECTED]>
Subject: Kernel message dupfd: fd 1040, max 1024
Date: Thu, 02 Sep 1999 16:41:47 +0200
Hi,
i get a lot of kernel messages like
dupfd: fd 1040, max 1024
with kernel 2.2.12. This happens always, when i shutdown
the informix database. The system runs fine, without any
problems.
The message comes from the dupfd call . I found the
call in the file linux/fs/fcntl.c . And here this message
seems only a warning, which i can comment out :
/* At this point, start MUST be <= max_fdset */
#if 1
if (start > files->max_fdset)
printk (KERN_ERR "dupfd: fd %d, max %d\n",
start, files->max_fdset);
#endif
newfd = fi
So can i safely remove this printk statement (or set the #if 1 to #if 0)
?
or may this cause any problems ?
Regards
Uli
--
Ulrich Eckhardt Tr@nscom GbR
http://people.frankfurt.netsurf.de/uli http://www.transcom.de
Lagerstra�e 11-15 A8
64807 Dieburg Germany
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: set up c++ development environment
Date: 02 Sep 1999 09:42:05 -0400
<[EMAIL PROTECTED]> writes:
> i am learning c++. i want to do c++ program under linux. what packages
> (rpm) do i need? what environment variable i need to set? and how i
> compile the source code?
you will want to install gcc-2.95.1, gcc-2.95.1-c++ with accompanying
libstdc++, and libstdc++-devel (i think libstdc++ has version
2.10.0). you'll want make and gdb too. as for editor, i like emacs,
although there are those who prefer vi or jed.
--
johan kullstam
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: IDE for c++ dev?
Date: 02 Sep 1999 09:31:11 -0400
Ian Thompson Bell <[EMAIL PROTECTED]> writes:
> Nix wrote:
>
> >
> >
> > After all, there is nothing that emacs cannot do. And that's
> > official.
> >
>
> Apart from be intuitive you mean?
why do you say this? if you are in X, emacs has menus and a mouse
interface. it's been this way for years now. if you can
point-n-click your way through, e.g., microsoft notepad, you can
point-n-click your way through emacs. there is an extensive menu
driven customization facility these days. what do you find
unintuitive?
those users who do not want/need the menus or mouse interface can turn
off menus easily enough and the keyboard commands and lisp engine are
always there for you.
emacs is a big large and slow to invoke. most emacs users work around
this by never quitting emacs. just like no one really cares about
linux boot times (since you reboot so seldom), so an emacs user never
leaves his beloved emacs.
i don't blame you for not liking emacs. that's ok. other editors
have their good points too. however, emacs really is easy to use
(i.e., easy to learn) right from the start and has the power needed to
stay easy to use in the long haul.
--
johan kullstam
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,redhat.general
Subject: Re: PCI card question
Date: 02 Sep 1999 09:37:38 -0400
zackary <[EMAIL PROTECTED]> writes:
> hello guys I would like to know why PCI sound card not supported by
> linux (I'm using linux redhat 6.0). Why only scsi slot sound card
> widely supported as nowdays its hard to find scsi slot sound card on
> sales. I ask the shop which sells pre installed linux in their pc
> about the sound card. And I would like to know are pci slot vga
> card supported by linux. Pls guide me. I'm quite despair when my PCI
> sound card undetected by linux. I could hear no sound. Thank
> you.-azaria-
dude, you posted that in one gigantic line. think about breaking
lines after 70 or chars.
you seem a bit confused. i don't think there is such a thing as a
`scsi slot'. nor have i ever heard of a scsi interfaced sound card.
linux hardware support is limited to (a fairly large collection of)
specific cards. all video cards will do console (text) mode. most
video cards have X support. sound support is sketchier. please post
your exact equipment. we need brand, model, model number, chipset
(try reading the manufacturer and numbers on the larger chips on the
card in question).
--
johan kullstam
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
