ruby-dev summary 26090-26127
Takaaki Tateishi
[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 <tt...@ttsky.net>
nobu....@softhome.net
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
Ara.T....@noaa.gov
> 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.
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
--
===============================================================================
| 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
===============================================================================
Tanaka Akira
Ara.T....@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
Ara.T....@noaa.gov
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.
Berger, Daniel
Whatever solution you decide on, please ensure it doesn't barf on Win32
afterwards.
Regards,
Dan
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
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