Re: short uid/gid

2002-10-16 Thread Terry Lambert
"Danny J. Zerkel" wrote: > To quote the POSIX standard: > > The ipc_perm structure shall contain the following members: > > uid_tuidOwner's user ID. > gid_tgidOwner's group ID. > uid_tcuid Creator's user ID. > gid_tcgid Creator's group ID. > mode_t mode Read/write

Re: short uid/gid

2002-10-16 Thread Danny J. Zerkel
On Wednesday 16 October 2002 13:01, Robert Watson wrote: > On Wed, 16 Oct 2002, Terry Lambert wrote: > > Robert Watson wrote: > > > I'm not convinced there's any value to providing the backward > > > compatibility that has to be asked for: the only benefit to the current > > > short-based API is t

Re: short uid/gid

2002-10-16 Thread Danny J. Zerkel
On Wednesday 16 October 2002 00:43, Robert Watson wrote: > On Tue, 15 Oct 2002, Danny J. Zerkel wrote: > > At least for our Linux emulation layer, supporting IPC_64 would be one > > of the pieces (probably the main one) keeping The Sims from running. > > The other thing we are missing is the Linux

Re: short uid/gid

2002-10-16 Thread Terry Lambert
Robert Watson wrote: > On Wed, 16 Oct 2002, Terry Lambert wrote: > > Robert Watson wrote: > > > I'm not convinced there's any value to providing the backward > > > compatibility that has to be asked for: the only benefit to the current > > > short-based API is that it allow serious security holes

Re: short uid/gid

2002-10-16 Thread Robert Watson
On Wed, 16 Oct 2002, Terry Lambert wrote: > Robert Watson wrote: > > I'm not convinced there's any value to providing the backward > > compatibility that has to be asked for: the only benefit to the current > > short-based API is that it allow serious security holes while not > > following the st

Re: short uid/gid

2002-10-16 Thread Terry Lambert
Robert Watson wrote: > I'm not convinced there's any value to providing the backward > compatibility that has to be asked for: the only benefit to the current > short-based API is that it allow serious security holes while not > following the standard API offered by other platforms (except Linux).

Re: short uid/gid

2002-10-16 Thread Terry Lambert
Maxim Sobolev wrote: > > You could also simply use non-intersecting cmd parameter values > > for the new calls, which avaids the special flag, and leaves the > > backward compatability without adding grundles of new system calls. > > What about source-level compatibility, which IMO is a good thin

Re: short uid/gid

2002-10-16 Thread Robert Watson
On Wed, 16 Oct 2002, Maxim Sobolev wrote: > > And it's not like the approach you've described makes it any easier to > > implement: you still have to break out the old and new structures since > > changing ipc_perm breaks the ABI for all of the System V interfaces, > > rewrite the kernel code, e

Re: short uid/gid

2002-10-16 Thread Maxim Sobolev
Robert Watson wrote: > > On Wed, 16 Oct 2002, Maxim Sobolev wrote: > > > What about source-level compatibility, which IMO is a good thing, at > > least if it doesn't add too much complexity (it clearly doesn't in this > > case)? Also, handling single flag should be easier from the coding > > per

Re: short uid/gid

2002-10-16 Thread Robert Watson
On Wed, 16 Oct 2002, Maxim Sobolev wrote: > What about source-level compatibility, which IMO is a good thing, at > least if it doesn't add too much complexity (it clearly doesn't in this > case)? Also, handling single flag should be easier from the coding > perspective than a load of new values,

Re: short uid/gid

2002-10-16 Thread Maxim Sobolev
On Wed, Oct 16, 2002 at 02:03:53AM -0700, Terry Lambert wrote: > Robert Watson wrote: > > While I think support for the IPC_64 flag under emulation is useful, I'd > > rather make use of compatibility system calls and type improvements for > > the base FreeBSD implementation of the System V IPC API

Re: short uid/gid

2002-10-16 Thread Terry Lambert
Robert Watson wrote: > While I think support for the IPC_64 flag under emulation is useful, I'd > rather make use of compatibility system calls and type improvements for > the base FreeBSD implementation of the System V IPC APIs. Most of the > work necessary to support those changes is required i

Re: short uid/gid

2002-10-15 Thread Robert Watson
On Tue, 15 Oct 2002, Danny J. Zerkel wrote: > At least for our Linux emulation layer, supporting IPC_64 would be one > of the pieces (probably the main one) keeping The Sims from running. > The other thing we are missing is the Linux ioctl() interface for > reading MSDOSFS directories, but that

Re: short uid/gid

2002-10-15 Thread Terry Lambert
"Danny J. Zerkel" wrote: > At least for our Linux emulation layer, supporting IPC_64 would be one > of the pieces (probably the main one) keeping The Sims from running. > The other thing we are missing is the Linux ioctl() interface for reading > MSDOSFS directories, but that may be optional. > >

Re: short uid/gid

2002-10-15 Thread Danny J. Zerkel
At least for our Linux emulation layer, supporting IPC_64 would be one of the pieces (probably the main one) keeping The Sims from running. The other thing we are missing is the Linux ioctl() interface for reading MSDOSFS directories, but that may be optional. I will eventually take a look at thi

Re: short uid/gid

2002-10-14 Thread Maxim Sobolev
Linux solved the problem by introducing a new flag for {msg,shm,sem}ctl(3) interfaces (IPC_64), which if set tells the kernel that user supplies new version of the structure. The kernel itself internally keeps all relevant information already in IPC_64 format, doing conversion before returning it

Re: short uid/gid

2002-10-14 Thread Robert Watson
Yeah, this is a Known Problem, and it's quite unfortunate, actually. I looked at trying to solve it -- changing the types respectively to uid_t, gid_t, and mode_t, but it involved a lot of ABI munging because the structures are shared between the userland interface and the kernel implementation.