Func umask problem?

[Nick Nachefski]

I'm using func to launch a process on remote machines. This process in turn generates some local files on those machines. It appears as if the files are being created with the umask 077.

Is this a bug with func?

I'm using 0.28.

________________________________
Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. Jump Trading, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial product.

[seth vidal]

I’m using func to launch a process on remote machines. This process
in turn generates some local files on those machines. It appears as
if the files are being created with the umask 077.
Is this a bug with func?

are you're using sendfile/putfile?

can you tell me which files you're talking about?

-sv

[Nick Nachefski]

I'm not using the send/putfile modules.

I had patched funcd to run as a non-root user. When I was using func to launch a custom module(a control script), the resulting daemonized process would create all files with a umask of 077. This was the case for both async and non-async modes.

To fix the issue, I just set the proper umask(022) in my func module prior to launching the process. Kind of a hack, but it doesn’t break func and my stuff gets created with proper perms.

Thanks!
Nick


-----Original Message-----
From: seth vidal [mailto:***@fedoraproject.org]
Sent: Monday, June 13, 2011 3:50 PM
To: Nick Nachefski
Cc: func-***@redhat.com
Subject: Re: [Func-list] Func umask problem?

I’m using func to launch a process on remote machines. This process
in turn generates some local files on those machines. It appears as
if the files are being created with the umask 077.
Is this a bug with func?

are you're using sendfile/putfile?

can you tell me which files you're talking about?

-sv






Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. Jump Trading, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial product.

[seth vidal]

Post by Nick Nachefski
I'm not using the send/putfile modules.
I had patched funcd to run as a non-root user. When I was using func to launch a custom module(a control script), the resulting daemonized process would create all files with a umask of 077. This was the case for both async and non-async modes.
To fix the issue, I just set the proper umask(022) in my func module prior to launching the process. Kind of a hack, but it doesn’t break func and my stuff gets created with proper perms.

well, I'm fairly certain some of the files are opened 600 - however the
jobthing spawner does call umask(077) when it runs something on the
minion.

that's probably where it is happening.

I'm not sure that's a bug, though.

what was the negative consequences?

-sv

ps: if your patches for running func as a non-root user are configurable
that might be worth sending to the list