Re: [PATCH 3/7] server: Implement object's security descriptor check against token.

[Robert Shearman]

Vitaliy Margolen wrote:
> +    res = token_access_check( token, obj->sd, *access, &priv, &priv_count,
> +                              &mapping, access, &status ) == STATUS_SUCCESS &&
> +          status == STATUS_SUCCESS;
> +    if (!res)
> +    {
> +        fprintf( stderr, "access check failed\n" );
> +        set_error( STATUS_ACCESS_DENIED );
> +    }

We don't want anything in the wineserver that can possibly spam the 
console, so this should be made conditional on debug_level being non-zero.

Also, is there any reason you return STATUS_ACCESS_DENIED instead of the 
statuses returned by token_access_check? Could you try writing a test 
that creates or opens an object with ACCESS_SYSTEM_SECURITY access and 
see if it returns STATUS_PRIVILEGE_NOT_HELD or STATUS_ACCESS_DENIED?

-- 
Rob Shearman

[PATCH 3/7] server: Implement object's security descriptor check against token.

[Vitaliy Margolen]

Robert Shearman wrote:
> Vitaliy Margolen wrote:
> > +    res = token_access_check( token, obj->sd, *access, &priv,
> > &priv_count,
> > +                              &mapping, access, &status ) ==
> > STATUS_SUCCESS &&
> > +          status == STATUS_SUCCESS;
> > +    if (!res)
> > +    {
> > +        fprintf( stderr, "access check failed\n" );
> > +        set_error( STATUS_ACCESS_DENIED );
> > +    }
>
> We don't want anything in the wineserver that can possibly spam the
> console, so this should be made conditional on debug_level being non-zero.
> In case we will have any problems related to security checks this will
> be really helpful troubleshooting them.
> Also, is there any reason you return STATUS_ACCESS_DENIED instead of the
> statuses returned by token_access_check? Could you try writing a test
> that creates or opens an object with ACCESS_SYSTEM_SECURITY access and
> see if it returns STATUS_PRIVILEGE_NOT_HELD or STATUS_ACCESS_DENIED?

The two programs I'm fixing does not require this. Nor do we handle it
properly anyway.

Vitaliy.