Here is a ruby-dev summaries:
[ruby-dev:26090] expand include path by -I
Nakada proposed that a path given with the command line option '-I'
be expanded at startup. This affects a library search path when we
change a working directory using Dir.chdir and so on. This proposal
have been accepted by Matz.
[ruby-dev:26100] FileUtils.rm_rf security problem
Tanaka warned of FileUtils.rm_rf since a user possibly changes files
which someone tries to delete via symlink attack like the following
situations about Perl.
http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rmtree
There are following two solutions.
* Use chdir.
* Change a permission to 700 and change a owner.
This issue is still open.
[ruby-dev:26107] variable name by -s
Nakada proposed to replace non-alphanumeric characters in global variables
defined by the command line option '-s' with '_', but Matz thought that such
a case results in an error. In the last result, '-' is replaced with '_' and
the other non-alphanumeric characters causes an error.
[ruby-dev:26122] ^C: [BUG] unknown node type 0
Tanaka raised a question about a file name "^C" that is
displayed when an error of "[BUG] unknown node type 0"
is caused. They haven't been decided how to fix it yet.
···
--
Takaaki Tateishi <ttate@ttsky.net>
Hi,
At Fri, 13 May 2005 00:08:45 +0900,
Takaaki Tateishi wrote in [ruby-talk:142388]:
[ruby-dev:26090] expand include path by -I
Nakada proposed that a path given with the command line option '-I'
be expanded at startup. This affects a library search path when we
change a working directory using Dir.chdir and so on. This proposal
have been accepted by Matz.
It is applied to only CVS trunk.
[ruby-dev:26122] ^C: [BUG] unknown node type 0
Tanaka raised a question about a file name "^C" that is
displayed when an error of "[BUG] unknown node type 0"
is caused. They haven't been decided how to fix it yet.
It is fixed in recent (today's) versions of both 1.8 and 1.9,
but more useful info would be better.
···
--
Nobu Nakada
what about making a tmpdir of 0700, moving to that, then cleaning the dir
under the tmp dir, and removing to tmpdir? i think just doing a chmod will
fail on nfs since it caches inode information...
-a
···
On Fri, 13 May 2005, Takaaki Tateishi wrote:
Here is a ruby-dev summaries:
[ruby-dev:26090] expand include path by -I
Nakada proposed that a path given with the command line option '-I'
be expanded at startup. This affects a library search path when we
change a working directory using Dir.chdir and so on. This proposal
have been accepted by Matz.
[ruby-dev:26100] FileUtils.rm_rf security problem
Tanaka warned of FileUtils.rm_rf since a user possibly changes files
which someone tries to delete via symlink attack like the following
situations about Perl.
http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rmtree
There are following two solutions.
* Use chdir.
* Change a permission to 700 and change a owner.
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
renunciation is not getting rid of the things of this world, but accepting
that they pass away. --aitken roshi
===============================================================================
In article <Pine.LNX.4.62.0505120944380.9643@harp.ngdc.noaa.gov>,
Ara.T.Howard@noaa.gov writes:
There are following two solutions.
* Use chdir.
* Change a permission to 700 and change a owner.
what about making a tmpdir of 0700, moving to that, then cleaning the dir
under the tmp dir, and removing to tmpdir? i think just doing a chmod will
fail on nfs since it caches inode information...
They are different ideas. They are not expected to combine.
···
--
Tanaka Akira
maybe i was unclear - i meant:
mkdir dir_to_be_removed.tmp
chmod 0700 dir_to_be_removed.tmp
mv dir_to_be_removed dir_to_be_removed.tmp # avoid race condition, ignore
# errors here
rm -rf dir_to_be_removed.tmp/dir_to_be_removed
rm -rf dir_to_be_removed.tmp/
- no race, even on nfs
- no security issue since all chmod'ing done during removal will happen
under a restricted directory
cheers.
-a
···
On Fri, 13 May 2005, Tanaka Akira wrote:
In article <Pine.LNX.4.62.0505120944380.9643@harp.ngdc.noaa.gov>,
Ara.T.Howard@noaa.gov writes:
There are following two solutions.
* Use chdir.
* Change a permission to 700 and change a owner.
what about making a tmpdir of 0700, moving to that, then cleaning the dir
under the tmp dir, and removing to tmpdir? i think just doing a chmod will
fail on nfs since it caches inode information...
They are different ideas. They are not expected to combine.
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
renunciation is not getting rid of the things of this world, but accepting
that they pass away. --aitken roshi
===============================================================================
In article <Pine.LNX.4.62.0505121149220.9643@harp.ngdc.noaa.gov>,
Ara.T.Howard@noaa.gov writes:
maybe i was unclear - i meant:
mkdir dir_to_be_removed.tmp
chmod 0700 dir_to_be_removed.tmp
mv dir_to_be_removed dir_to_be_removed.tmp # avoid race condition, ignore
# errors here
rm -rf dir_to_be_removed.tmp/dir_to_be_removed
rm -rf dir_to_be_removed.tmp/
- no race, even on nfs
I'm not sure about NFS issue.
- no security issue since all chmod'ing done during removal will happen
under a restricted directory
A malicious user may have a process which current working directory is
a directory in the restricted directory.
Is the restriction enough to be secure?
···
--
Tanaka Akira