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
correctly. To be able > > > to run properly on other platforms (vis Solaris), they already should > > > be using those types. > > > > Truncating of oversized values for credentials is Bad(tm), in that what > > you get is a different credential. The constraint ha

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
versized values for credentials is Bad(tm), in that what > > you get is a different credential. The constraint has to be a priori > > enforced, or it's meaningless. > > I think we're in agreement here. Unfortunately, because of the "short" > uid/gid/cu

Re: short uid/gid

2002-10-16 Thread Robert Watson
what > you get is a different credential. The constraint has to be a priori > enforced, or it's meaningless. I think we're in agreement here. Unfortunately, because of the "short" uid/gid/cuid/cgid fields, truncation is *already* happening. That's what we're t

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
ustedBSD Projects > > [EMAIL PROTECTED] Network Associates Laboratories > > > > On Mon, 14 Oct 2002, Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info wrote: > > > Hi > > > > > > I have found that SysVIPC functions uses structure with

Re: short uid/gid

2002-10-14 Thread Maxim Sobolev
TECTED] Network Associates Laboratories > > On Mon, 14 Oct 2002, Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info >wrote: > > > > > Hi > > > > I have found that SysVIPC functions uses structure with short uid/gid types. > > >

Re: short uid/gid

2002-10-14 Thread Robert Watson
, 14 Oct 2002, Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info wrote: > > Hi > > I have found that SysVIPC functions uses structure with short uid/gid types. > > What is valid solution ? > > Change types to uid_t/gid_t (but this will broke binary compatibi

short uid/gid

2002-10-14 Thread Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info
Hi I have found that SysVIPC functions uses structure with short uid/gid types. What is valid solution ? Change types to uid_t/gid_t (but this will broke binary compatibility) Change syscalls to old_* and add new with "right" structures, or something else ? struct ipc_perm {