Mailing-List:	contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-developers/>
List-Post:	<mailto:cygwin-developers AT cygwin DOT com>
List-Help:	<mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-developers-owner AT cygwin DOT com
Delivered-To:	mailing list cygwin-developers AT cygwin DOT com
Message-ID:	<086801c20fd9$dc59d5b0$6132bc3e@BABEL>
From:	"Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
To:	<cygwin-developers AT cygwin DOT com>
References:	<072501c20fb8$8d16dc80$6132bc3e AT BABEL> <20020609163607 DOT GD26171 AT redhat DOT com>
Subject:	Re: shm status
Date:	Sun, 9 Jun 2002 18:19:49 +0100
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2600.0000

"Christopher Faylor" <cgf AT redhat DOT com> wrote:
> On Sun, Jun 09, 2002 at 02:21:22PM +0100, Conrad Scott wrote:
> >Also the ipcs and ipcrm utitilities are really useful when working with
sysv
> >ipc so I also thought I could start by adding these. Presumably this
would
> >be a case for another cygwin_internal() interface? i.e. get the list of
ids;
> >the program then issues xxxctl() calls to get the relevant details or rm
the
> >requested objects. Any objections to such an approach? (Just for
> >comparison, the usual Un*x implementation involves reading kernel
> >memory via /dev/kmem.)
>
> Do we need a cygwin_internal interface?  How do OSes like linux do this?
>
> Maybe it makes sense to start exposing things via the /proc interface, if
that
> is the way linux does it.

Umm . . . I was trying really hard to avoid going down that route but you're
probably right.

I was thinking of a simple interface that provided a list of current shmids
via the cygwin_internal interface (which would need to get them from the
cygserver AFAICT); the ipcs program would then use shmctl(2) to get
information on them. That way the current permission checking in shmctl(2)
would do most of the security work for me (i.e. getting a list of shmids is
not a security hole since you can't do anything with them unless you've got
access permission to them anyway).

I'll go and have a look at what linux does here. I've checked NetBSD et al.
and they use the tried and trusted /dev/kmem route (via kvm_openfiles() but
still . . .) and my memory of most of the commercial Un*xes I've used is
that they go the same route but that "knowledge" might be stale by now.

Cheers,

// Conrad

- Raw text -