On 13/06/12 11:48 +1000, Andrew Beekhof wrote:
On 13/06/2012, at 11:34 AM, Gao,Yan wrote:
> Hi Andrew,
>
> On 06/13/12 07:18, Andrew Beekhof wrote:
>>
>> On 12/06/2012, at 10:45 PM, Gao,Yan wrote:
>>
>>> On 06/12/12 19:56, Gao,Yan wrote:
>>>> Hi Angus,
>>>> Thanks a lot for introducing this! I also added the following patch,
>>>> modified "examples/ipcserver.c", and it works for both
QB_IPC_SHM and
>>>> QB_IPC_SOCKET mode in the example.
>>>>
>>>> I encountered weird behaviors for pacemaker cib though. Chmod works
>>>> fine, but the group of file has never been changed. The only difference
>>>> I can think of is that cib's uid "hacluster" comes from
setuid() by
>>>> root. But it still doesn't make sense to me that it's not allowed
to
>>>> change the group of a file to "hacluster"'s main group...
>>> So it is, "hacluster" got from setuid() by root cannot change the
group
>>> of a file to "hacluster"'s main group -- "haclient",
unless we also
>>> setgid to "haclient" before setuid to "hacluster",
otherwise "root" must
>>> belong to "haclient" group.
>>
>> Really? That would surprise me greatly.
> Me too. :-\ It seems setuid() doesn't change any of the group
> information of the process unless setgid() _before_ that -- setgid()
> after setuid() is not allowed either.
I thought "unpriv client -> root server" and "root client -> unpriv
server" both worked already.
I might have fallen behind, could you restate the problem?
I think the issue here is the server is non-root-user:root-group And
the client is non-root-user:non-root-group.
So server can't chown the file it created to be the uid of the client.
What we are trying to do now is:
chgrp the file to a common group and chmod to 0660.
This works for me (for 2 different users with a common group).
But Yan is struggling with the server as it gets the group id
via setgid().
-Angus
>
>> How does chgrp manage this?
> It invokes fchownat() system call. And it behaves in the same way as
> chown() for this.
Can we not do this too?
>
>>
>>> Another way is to change the file mode to
>>> 0666, and determine permissions in connection_accept().
>>>
>>> Andrew, opinions?
>>
>> Leaving the permissions wide open doesn't sound very appealing.
> Hmm, not very ideal indeed.
>
> Regards,
> Gao,Yan
> --
> Gao,Yan <ygao(a)suse.com>
> Software Engineer
> China Server Team, SUSE.
_______________________________________________
quarterback-devel mailing list
quarterback-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/quarterback-devel