Re: Strange behavior from unlink() Unix-type API

[Pete Hall <pete@xxxxxxxxxxxxxx>]

Try looking at the authorities with the native i command (I think) it's 
WRKLNK. There are two sets of authorities on ifs objects. One is the unix/
linux type data authorities (rwx), but there is also a set of object 
authorities, which may prohibit you from creating or deleting objects.

On Fri, 12 Aug 2011 17:09:49 -0700, James Lampert wrote:

> Jack Kingsley wrote:
> > no AUTL's involved.
>
> None that I'm aware of, and I have some unexpected results:
>
> Stepping through the program that creates these objects, first it
> executes:
> > docDescriptor = open(canonicalPath,
> >   O_CODEPAGE|O_CREAT|O_WRONLY|O_TRUNC, S_IRWXU|S_IRWXO, 819);
> > if (docDescriptor != -1) {
> >        /* First, try to give the object to the group! */
> >     if (memcmp(usri0300.Group_Profile, "*NONE", 5) != 0)
>
> At this point, I've got a breakpoint. I looked at the IFS object, and I
> find that its authorities are ALREADY:
> > > *PUBLIC     *RWX         X     X     X     X JAMESL      *RWX
>
> So I step it through:
> >    i = fchown(docDescriptor, usri0300g.UID, 0); j = errno;
>
> and I get (at this point, not unexpectedly) i=-1, and j=3027 (EPERM --
> Operation Not Permitted).
>
> So it's not screwing up the authorities when I attempt to change the
> owner; it's screwing them up the moment the file is created!
>
> Anybody have any idea why THAT would happen?

Try looking at the authorities with the native i command (I think) it's 
WRKLNK. There are two sets of authorities on ifs objects. One is the unix/
linux type data authorities (rwx), but there is also a set of object 
authorities, which may be prohibit you from creating or deleting objects.