Re: struct ipc_perm

2003-06-20 Thread Robert Watson

On Wed, 18 Jun 2003, Dmitry Sivachenko wrote:

   Is there any reason why struct ipc_perm is not protected by #ifdef _KERNEL
   in ipc.h?  Is it supposed to be used from userland?
  
  It's needed by ipcs.
 
 Ah, I see.  It is visible via struct msqid_ds. 
 
 I developed a patch which requires addition of custom field to ipc_perm. 
 I am trying to imagine which problems can it cause to userland programs. 

We have local changes in the TrustedBSD development trees to extend all
the structures in the kernel without modifying the ABI.  We needed this to
put labels in the various System V IPC object structures.  We're not ready
to merge them yet, but it will probably happen in the next month or so.
If you'd like early access to the patch, we can drop you a copy.  We'll
merge it into the MAC tree in about a week.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: struct ipc_perm

2003-06-19 Thread Gary Jennejohn

Dmitry Sivachenko writes:
 On Wed, Jun 18, 2003 at 06:08:37PM +0200, Gary Jennejohn wrote:
  
  Dmitry Sivachenko writes:
   Hello!
   
   Is there any reason why struct ipc_perm is not protected by #ifdef _KERNE
 L
   in ipc.h?  Is it supposed to be used from userland?
   
  
  It's needed by ipcs.
  
 
 Ah, I see.  It is visible via struct msqid_ds.
 
 I developed a patch which requires addition of custom field to ipc_perm.
 I am trying to imagine which problems can it cause to userland programs.
 
 Any ideas?
 

The usual way to handle this sort of change is to put any new structure
elements at the end so that existing applications don't get confused.
They simply aren't aware the new elements were added.

Of course, this can cause problems when the kernel does a copyout()
using the new size but the application passed a pointer to
storage which can only hold the old, smaller structure.

---
Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org gj[at]denx.de

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: struct ipc_perm

2003-06-19 Thread Dmitry Sivachenko
On Thu, Jun 19, 2003 at 10:56:41AM +0200, Gary Jennejohn wrote:
 
 Dmitry Sivachenko writes:
  On Wed, Jun 18, 2003 at 06:08:37PM +0200, Gary Jennejohn wrote:
   
   Dmitry Sivachenko writes:
Hello!

Is there any reason why struct ipc_perm is not protected by #ifdef _KERNE
  L
in ipc.h?  Is it supposed to be used from userland?

   
   It's needed by ipcs.
   
  
  Ah, I see.  It is visible via struct msqid_ds.
  
  I developed a patch which requires addition of custom field to ipc_perm.
  I am trying to imagine which problems can it cause to userland programs.
  
  Any ideas?
  
 
 The usual way to handle this sort of change is to put any new structure
 elements at the end so that existing applications don't get confused.
 They simply aren't aware the new elements were added.

Yes, that is exactly how I did it.


 
 Of course, this can cause problems when the kernel does a copyout()
 using the new size but the application passed a pointer to
 storage which can only hold the old, smaller structure.

I didn't guess that.  Probably this is why X-server crashed on my machine
after that change.  Recompilation fixed the problem.

Thank you.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: struct ipc_perm

2003-06-19 Thread Philip Reynolds
Gary Jennejohn [EMAIL PROTECTED] 38 lines of wisdom included:
 
 Dmitry Sivachenko writes:
  Any ideas?
  
 
 The usual way to handle this sort of change is to put any new structure
 elements at the end so that existing applications don't get confused.
 They simply aren't aware the new elements were added.
 
 Of course, this can cause problems when the kernel does a copyout()
 using the new size but the application passed a pointer to
 storage which can only hold the old, smaller structure.

Yeh, recompiling any applications using it, should work.
They'll pick up the sizeof() the modified struct.

-- 
Philip Reynolds  | RFC Networks Ltd.
[EMAIL PROTECTED]  | +353 (0)1 8832063
http://people.rfc-networks.ie/~phil  | www.rfc-networks.ie
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: struct ipc_perm

2003-06-18 Thread Gary Jennejohn

Dmitry Sivachenko writes:
 Hello!
 
 Is there any reason why struct ipc_perm is not protected by #ifdef _KERNEL
 in ipc.h?  Is it supposed to be used from userland?
 

It's needed by ipcs.

---
Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org gj[at]denx.de

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: struct ipc_perm

2003-06-18 Thread Dmitry Sivachenko
On Wed, Jun 18, 2003 at 06:08:37PM +0200, Gary Jennejohn wrote:
 
 Dmitry Sivachenko writes:
  Hello!
  
  Is there any reason why struct ipc_perm is not protected by #ifdef _KERNEL
  in ipc.h?  Is it supposed to be used from userland?
  
 
 It's needed by ipcs.
 

Ah, I see.  It is visible via struct msqid_ds.

I developed a patch which requires addition of custom field to ipc_perm.
I am trying to imagine which problems can it cause to userland programs.

Any ideas?

Thanks!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]