Re: IPC bugs / FIFOs

From: Amon Ott <ao@rsbac.org>
Subject: Re: IPC bugs / FIFOs
Date: Mon, 18 Dec 2000 10:58:38 +0100

Next Article (by Author): v1.1.0 download statistics Amon Ott
Previous Article (by Author): Re: IPC bugs / FIFOs Amon Ott
Top of Thread: Re: IPC bugs / FIFOs Amon Ott
Articles sorted by: [Date] [Author] [Subject]

On Fre, 15 Dez 2000 staringer wrote:
> Hello Amon!
> Amon Ott wrote:
> 
> > On Mit, 13 Dez 2000 staringer wrote:
> > > Amon Ott wrote:
> > >
> > > > On Sam, 09 Dez 2000 Stanislav Ievlev wrote:
> > > > > There are problems with some IPC objects:
> > > >
> > > > OK, FIFOs where hacked in without much reflection. Functionally, they belong to
> > > > the IPC object family, but their system representation is as files.
> > > >
> > > > What do you prefer:
> > > >
> > > > - FIFOs are treated as FILE objects
> > > > - FIFOs are treated as IPC objects
> > > >
> > >
> > > Well, I prefer FIFOs as IPC objects.
> >
> > After thinking about it:
> >
> > - FIFOs are no files
> > - the RSBAC data structures for files already exist and could be used
> > - IPC-fifo would have to be created with device sets, because FIFOs are device
> > dependent
> >
> > So I suggest a new target type T_FIFO, which could be kept in the same data
> > structures as T_FILE and T_DIR. The decisions, syscalls and tools for files and
> > dirs can easily be extended for FIFOs, so the whole infrastructure is almost
> > there. FIFOs could even inherit attributes, ACLs etc. from the DIR they are in.
> >
> > What do you think?
> >
> 
> T_FIFO ... it's very interesting. But what about link (may be logical) T_FIFO with
> T_IPC?

This would mean a lot of additional if clauses. So I would rather introduce
T_FIFO, if nobody protests. This gives the additional benefit of a (possible)
separate request group for FIFO_REQUESTS.

Amon.
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.