bug-hurd
[Top][All Lists]
Advanced

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

Re: System V Shared Memory


From: Neal H Walfield
Subject: Re: System V Shared Memory
Date: 16 Apr 2002 00:16:16 -0400
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1

> I have a couple of questions on your implementation, however, that I
> just
> don't understand.  You commented out the entire 'IPC_SET' case from the
> shmctl function.  I'm not clear on why you did this.  How else can we
> enforce permissions on shared memory segments?  I'm not sure why you
> object to using __file_chown() to do this.  I would think that using 
> chown/chmod would be better than nothing, but what do I know.

My problem is not so much with setting the owner and changing the file
mode, but rather, using the author field for the creator uid and the
flags for the pid of the last operation, etc.  Please understand that
I was sloppy as it was not my intention to decide what to overload
with what data.  Rather, I would like to open up discussion and get
some other people's input.  So, more formally, here are what we need
to save:

  shmid_ds.shm_lpid      PID of whoever made the last shm operation
  shmid_ds.shm_cpid      PID of the creator
  shmid_ds.shm_nattach   Number of total attaches
  shm_perm.cuid          EUID of creator
  shm_perm.guid          EGID of creator

> Secondly, why is it not acceptable to use hurd rpc's in glibc?

No, I think it is acceptable, however, in this particular case, it is
my opinion that the Hurd rpcs are at a lower level than we need to
address directly: the libc functions give us enough control and manage
some of the details.  Perhaps others will disagree with this decision,
please comment.

> I ran into this as well and had exactly the same thoughts you did.  The
> only thing that I could think to do was to provide an additional RPC
> at the filesystem to provide these functions.  That was _sort-of_
> the intent with 'chauthor' in that perhaps we create a new RPC
> for these things specific to SHM and make it so that if the RPCs
> are not implemented, we don't fail hard, we just don't provide all the
> data.  That way, we could use SHM on normal filesystems but not get
> all of the accounting information on them.

Generally, Roland has expressed a certain (i.e. an understandably
large) amount of resistance to any interface changes (e.g. adding any
new RPCs) without a significant amount of justification.  And at this
point in the discussion, I do not think that we have explored all of
the possibilities.

> The problem with putting the data in another file or in the file
> itself is that it will be nearly impossible to ensure that no-one
> can come along behind you and corrupt it, remove it, etc.

Well, the same holds for the fields, so, this is not a valid argument.


By the way, please do not feel bad that I rewrote your patch.  I am
sure that once Roland takes some time to look at my proposal, he will
make it equally unrecognizable.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]