POSIX Message Queues

POSIX Message Queues

[Ardhan Madras]

    I'm hacking a program that need to do several *privileged* tasks, such as getting ethernet's link status (ioctl's SIOCETHTOOL command), setting and saving system time, and many more, this program must run in regular user mode (unprivileged), let's call this program as 'A'. I created another program (program 'B') as service than run in privileged mode to do privileged tasks above. I'm using POSIX message queue to exchange data as follow:

struct data {
    unsigned char cmd;
    long value;
};

Creating a queue in program B:

struct mq_attr attr = { .mq_maxmsg = 1, .mq_msgsize = sizeof(struct data) };
mqd_t mqd = open("/somename", O_RDWR | O_CREAT, 0777, &attr);

Open that queue in program A:

mqd_t mqd = open("/somename", O_RDWR); /* O_RDONLY should works here */

With given queue, i can't open this queue in program A with O_RDWR or O_WRONLY flag (O_RDONLY should works), no matter how i set the flag mode in program B's mq_open() i got EACCESS, i need both program can send and receive queues.

Did i miss something here?

                            Ardhan,


_____________________________________________________________
Listen to KNAC, Hit the Home page and Tune In Live! ---> http://www.knac.com

Re: POSIX Message Queues

[Glynn Clements]

Ardhan Madras wrote:

> I'm using POSIX message queue to exchange data as follow:
> 
> struct data {
>     unsigned char cmd;
>     long value;
> };
> 
> Creating a queue in program B:
> 
> struct mq_attr attr = { .mq_maxmsg = 1, .mq_msgsize = sizeof(struct data) };
> mqd_t mqd = open("/somename", O_RDWR | O_CREAT, 0777, &attr);
> 
> Open that queue in program A:
> 
> mqd_t mqd = open("/somename", O_RDWR); /* O_RDONLY should works here */

I presume that you mean mq_open() rather than open(), right?

> With given queue, i can't open this queue in program A with O_RDWR or
> O_WRONLY flag (O_RDONLY should works), no matter how i set the flag
> mode in program B's mq_open() i got EACCESS, i need both program can
> send and receive queues.
> 
> Did i miss something here?

The requested permissions have the process' umask subtracted from
them. Unless you've changed it, the umask probably removes at least
world-write permission, and possibly others. Either clear the umask
before calling mq_open(), or set the permissions afterwards with
fchmod() (although I don't know whether the latter is portable).

Also, if the queue already exists, mq_open(O_CREAT) will open the
existing queue; it won't replace it or change the permissions. Add
O_EXCL if you want it to fail if a queue with the same name already
exists.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: POSIX Message Queues

[Ardhan Madras]

It was mq_open(), sorry my bad ;p

I did umask(0001) before creating the queue, it's works now. 'Program A' that requested O_RDWR flag to the queue can send and receive message as 'Program B' did. I also try to demonstrating this problem with another machine (Linux of course), as result i can O_RDWR'ed program A queue flag without have to call umask() first. Is this behavior can be set through system configuration?

fchmod() also works here, sorry, but what do you mean with 'not portable'?, do you mean fchmod() intended to be used only for file, in other words "not every system support fchmod() with message queue descriptor" right?

               Ardhan,


--- glynn@gclements.plus.com wrote:

From:	Glynn Clements <glynn@gclements.plus.com>
To:	<ajhwb@knac.com>
Cc:	<linux-c-programming@vger.kernel.org>
Subject: Re: POSIX Message Queues
Date:	Sat, 12 Jun 2010 14:40:07 +0100


Ardhan Madras wrote:

> I'm using POSIX message queue to exchange data as follow:
> 
> struct data {
>     unsigned char cmd;
>     long value;
> };
> 
> Creating a queue in program B:
> 
> struct mq_attr attr = { .mq_maxmsg = 1, .mq_msgsize = sizeof(struct data) };
> mqd_t mqd = open("/somename", O_RDWR | O_CREAT, 0777, &attr);
> 
> Open that queue in program A:
> 
> mqd_t mqd = open("/somename", O_RDWR); /* O_RDONLY should works here */

I presume that you mean mq_open() rather than open(), right?

> With given queue, i can't open this queue in program A with O_RDWR or
> O_WRONLY flag (O_RDONLY should works), no matter how i set the flag
> mode in program B's mq_open() i got EACCESS, i need both program can
> send and receive queues.
> 
> Did i miss something here?

The requested permissions have the process' umask subtracted from
them. Unless you've changed it, the umask probably removes at least
world-write permission, and possibly others. Either clear the umask
before calling mq_open(), or set the permissions afterwards with
fchmod() (although I don't know whether the latter is portable).

Also, if the queue already exists, mq_open(O_CREAT) will open the
existing queue; it won't replace it or change the permissions. Add
O_EXCL if you want it to fail if a queue with the same name already
exists.

-- 
Glynn Clements <glynn@gclements.plus.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




_____________________________________________________________
Listen to KNAC, Hit the Home page and Tune In Live! ---> http://www.knac.com

Re: POSIX Message Queues

[Glynn Clements]

Ardhan Madras wrote:

> It was mq_open(), sorry my bad ;p
> 
> I did umask(0001) before creating the queue, it's works now. 'Program
> A' that requested O_RDWR flag to the queue can send and receive
> message as 'Program B' did. I also try to demonstrating this problem
> with another machine (Linux of course), as result i can O_RDWR'ed
> program A queue flag without have to call umask() first. Is this
> behavior can be set through system configuration?

A process' umask is inherited from its parent. For interactive
sessions, you can set it in your ~/.profile or similar. For daemons
started by init, you can set it in the rc script which starts the
daemon.

> fchmod() also works here, sorry, but what do you mean with 'not
> portable'?, do you mean fchmod() intended to be used only for file, in
> other words "not every system support fchmod() with message queue
> descriptor" right?

Yes.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: POSIX Message Queues

[Ardhan Madras]

Hi all,

        I use message queue to exchange data between 2 unrelated process, as shown below

Program A:
while (1) {
    mq_receive(); /* wait and receive request */
    /* process request */
    mq_send(); /* reply the request result */
}

Program B:
mq_send(); /* send request */
mq_receive(); /* process result */

        How it's possible to process A that call mq_send() receive it's *own* send data using mq_receive(), so process B that intended to read the message (mq_receive()) could not read it?, the problem is *sometime* happen, at most program A reply what program B requested. Did I miss something here?

        Ardhan



--- glynn@gclements.plus.com wrote:

From: Glynn Clements <glynn@gclements.plus.com>
To: <ajhwb@knac.com>
Cc: <linux-c-programming@vger.kernel.org>
Subject: Re: POSIX Message Queues
Date: Tue, 15 Jun 2010 16:33:25 +0100


Ardhan Madras wrote:

> It was mq_open(), sorry my bad ;p
> 
> I did umask(0001) before creating the queue, it's works now. 'Program
> A' that requested O_RDWR flag to the queue can send and receive
> message as 'Program B' did. I also try to demonstrating this problem
> with another machine (Linux of course), as result i can O_RDWR'ed
> program A queue flag without have to call umask() first. Is this
> behavior can be set through system configuration?

A process' umask is inherited from its parent. For interactive
sessions, you can set it in your ~/.profile or similar. For daemons
started by init, you can set it in the rc script which starts the
daemon.

> fchmod() also works here, sorry, but what do you mean with 'not
> portable'?, do you mean fchmod() intended to be used only for file, in
> other words "not every system support fchmod() with message queue
> descriptor" right?

Yes.

-- 
Glynn Clements <glynn@gclements.plus.com>




_____________________________________________________________
Listen to KNAC, Hit the Home page and Tune In Live! ---> http://www.knac.com