ruby-dev summary 24054-24170

[Masayoshi Takahashi]

Hi all,

This is a summary of ruby-dev ML these days.


[ruby-dev:24106] return value of Process.daemon

Now Process.daemon is implemented in Ruby HEAD branch, but
Tanaka Akira, who made the request of this method in
[ruby-dev:24030], suggested that Process.daemon should return
nil, not 0, on the contrary of current implementation.

Matz told his opinion that methods coresponding with
system calls or library functions should return
their return values without any change.


[ruby-dev:24140] CGI::Session has security problem?

Takahiro Kambe introduced Debian Security Advisory DSA 537-1
(http://www.debian.org/security/). The document is about
Vulnerability of insecure file permissions.

Matz answered that Ruby 1.8.2, 1.6.8 on CVS and HEAD are fixed,
but he thought any CGI scripts using CGI::Session should use
umask, because they cannot explicitly define file permissions of
new files created by fopen(3) without umask.


[ruby-dev:24143] problem in execution of external command in here document

Tome reported the problem of external command execution in here document
on mswin32.

#bad
p <<`EOC`
ls.exe
EOC

#good
p `ls.exe`

This problem is because the interpreter tries to execute
"ls.exe\n" without chomp "\n", but Windows shell cannot treat
it.

U.Nakamura promised that he'll add something to handle this
problem.


[ruby-dev:24156] CGI::Session::FileStore should not use Dir::tmpdir

Shugo Maeda pointed out the problem of CGI::Session::FileStore.
The module used Dir::tmpdir as default value of parameter 'tmpdir'.
Suppose Dir::tmpdir is '/tmp', users which have permissions to
login the server can see session file's name, so he can know
session ids without opening session files.

Shugo gave the idea from IRC that increase the length of
session id and put the remains into its file.
Matz showed other solution to use one-way function once more
to convert session id into filename.


Regards,

TAKAHASHI 'Maki' Masayoshi E-mail: (e-mail address removed)

 

[Daniel Berger]

Hi all,

This is a summary of ruby-dev ML these days.
[ruby-dev:24106] return value of Process.daemon

Now Process.daemon is implemented in Ruby HEAD branch, but
Tanaka Akira, who made the request of this method in
[ruby-dev:24030], suggested that Process.daemon should return
nil, not 0, on the contrary of current implementation.

Matz told his opinion that methods coresponding with
system calls or library functions should return
their return values without any change.

For those operating systems (e.g. Solaris) that don't have the
daemon() function, what about calling umask(0) and normalizing the
PATH?

And for the hyper paranoid, Stevens recommends calling fork twice.

Regards,

Dan

 

[ts]

D> For those operating systems (e.g. Solaris) that don't have the
D> daemon() function, what about calling umask(0) and normalizing the
D> PATH?

source of *BSD


int
daemon(int nochdir, int noclose)
{
int fd;

switch (fork()) {
case -1:
return (-1);
case 0:
break;
default:
_exit(0);
}

if (setsid() == -1)
return (-1);

if (!nochdir)
(void)chdir("/");

if (!noclose && (fd = open(_PATH_DEVNULL, O_RDWR, 0)) != -1) {
(void)dup2(fd, STDIN_FILENO);
(void)dup2(fd, STDOUT_FILENO);
(void)dup2(fd, STDERR_FILENO);
if (fd > 2)
(void)close (fd);
}
return (0);
}



Guy Decoux

 

[Daniel Berger]

D> For those operating systems (e.g. Solaris) that don't have the
D> daemon() function, what about calling umask(0) and normalizing the
D> PATH?

source of *BSD


int
daemon(int nochdir, int noclose)
{
int fd;

switch (fork()) {
case -1:
return (-1);
case 0:
break;
default:
_exit(0);
}

if (setsid() == -1)
return (-1);

if (!nochdir)
(void)chdir("/");

if (!noclose && (fd = open(_PATH_DEVNULL, O_RDWR, 0)) != -1) {
(void)dup2(fd, STDIN_FILENO);
(void)dup2(fd, STDOUT_FILENO);
(void)dup2(fd, STDERR_FILENO);
if (fd > 2)
(void)close (fd);
}
return (0);
}



Guy Decoux

So, are you saying that we don't need it, or that the daemon()
function is incomplete?

I guess we just have to remember to do it on our own then.

Dan

 

[ts]

D> So, are you saying that we don't need it, or that the daemon()
D> function is incomplete?

yes, more precisely when the daemon() function is not implemented in a
system then ruby must do exactly like the BSD version.




Guy Decoux

 

[Ara.T.Howard]

D> So, are you saying that we don't need it, or that the daemon()
D> function is incomplete?

yes, more precisely when the daemon() function is not implemented in a
system then ruby must do exactly like the BSD version.

i always use a double fork - you feel this is enough though?

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[ts]

A> i always use a double fork - you feel this is enough though?

Well in the BSD daemon() there is only a single fork(), if ruby want to
emulate daemon() on other systems it must use only a single fork()


Guy Decoux

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 24054-24170"
on Thu, 2 Sep 2004 23:16:12 +0900, (e-mail address removed) writes:

|i always use a double fork - you feel this is enough though?

Since the calling process dies in the daemon(), there's no need for
double fork.

matz.

 

[Ara.T.Howard]

Hi,

In message "Re: ruby-dev summary 24054-24170"
on Thu, 2 Sep 2004 23:16:12 +0900, (e-mail address removed) writes:

|i always use a double fork - you feel this is enough though?

Since the calling process dies in the daemon(), there's no need for
double fork.

matz.

here's a snip from some code i'm running as we speak - i stole the code from
open3, which seemed to agree with steven's book (if memory serves me):

def daemon
#{{{
if opt_daemon
fork do
Process.setsid
fork do
Dir.chdir(Util.realpath('~'))
open('/dev/null','r+') do |f|
STDIN.reopen f
STDOUT.reopen f
STDERR.reopen f
end
daemon_wrap{ yield }
exit EXIT_SUCCESS
end
exit!
end
exit!
else
daemon_wrap{ yield }
exit EXIT_SUCCESS
end
#}}}
end
def daemon_wrap
#{{{
begin
yield
rescue Exception => e
unless SystemExit === e or opt_quiet
fatal{ e } rescue nil
end
exit EXIT_FAILURE
end
#}}}
end

i guess open3 needs it (the 2x fork) because there the calling process does
__not__ exit, in my code however, it does. so the double fork is needed to
'spawn a daemon process' and a single fork is o.k. to 'become a daemon'.
sound correct? it seems like there is never any harm in having a double fork
though, is there?

cheers.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 24054-24170"
on Fri, 3 Sep 2004 00:15:23 +0900, (e-mail address removed) writes:

|i guess open3 needs it (the 2x fork) because there the calling process does
|__not__ exit, in my code however, it does. so the double fork is needed to
|'spawn a daemon process' and a single fork is o.k. to 'become a daemon'.
|sound correct?

When you understand the reason for double fork, things will be clear.

Processes will be zombies (half dead process during process
termination) until their parents call wait(2) for them. A daemon is a
long living process, and should be detached from parent processes. So
here's the trick. When parent processes die, child processes will be
adopted to init (pid=1) which calls wait(2) for its adopted children,
so that they will no longer become zombies. Double fork is worked
this way.

In open3, double forks are 1) first fork just to die to pass its child
to init, 2) second fork that eventually exec the command. In daemon,
double forks are 1) the calling interpreter itself (it's dying in
daemon), and 2) the child process that become a daemon.

|it seems like there is never any harm in having a double fork
|though, is there?

So if I understand you correctly, yours have triple forks instead of
two. One extra fork harms little. Very small cost for an extra
process creation.

matz.

 

[Tanaka Akira]

Processes will be zombies (half dead process during process
termination) until their parents call wait(2) for them. A daemon is a
long living process, and should be detached from parent processes. So
here's the trick. When parent processes die, child processes will be
adopted to init (pid=1) which calls wait(2) for its adopted children,
so that they will no longer become zombies. Double fork is worked
this way.

There is another reason for a fork after setsid: prevent unexpected
acquiring of a controling terminal.
[ruby-talk:87467], [ruby-talk:87500]

However the unexpected acquiring doesn't occur under 4.4BSD kernel
because open(2) doesn't acquire a controling terminal. But Linux
does.

I'm not sure that glibc's daemon(3) implementation is proper.

Note that uClibc's daemon(3) does fork after setsid.

In open3, double forks are 1) first fork just to die to pass its child
to init, 2) second fork that eventually exec the command.

The second fork is not required to avoid zombies.

So if I understand you correctly, yours have triple forks instead of
two. One extra fork harms little. Very small cost for an extra
process creation.

Yes. It is very small cost.