Re: [chromium-dev] opening local files with chrome from command line, relative paths
On Sat, Jan 9, 2010 at 3:06 PM, Victor Khimenko k...@google.com wrote: P.S. There are interesting fact related to specifically colon and MacOS. Classic MacOS uses colon as delimeter and you can use slash in filename. when they used POSIX-compliat kernel they needed some way to resolve thus collision. The solution was simple and elegant: they swapped colon and slash - so if you'll create http: directory old MacOS 9 program will see http/ directory. Thus you can create file which looks as http://google.com; for unix-programs and for MacOS programs (even if it'll be two different files). Long long ago, we spent an evening trying to delete a file on an SGI machine which had been created with an embedded '/' character from an early Mac NFS client. The client could _create_ such files, but it couldn't delete them... eventually we found a command or system call or something to do a remove by inode and were golden. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
On Sat, Jan 9, 2010 at 6:08 AM, Antoine Labour pi...@google.com wrote:
How about:
int fd = open(file_or_url, O_RDONLY);
if (fd = 0) {
close(fd);
OpenLocalFile(file_or_url);
} else {
OpenURL(file_or_url);
}
Security risk. It's fine for interactive work (eve then it's risky), but
when script opens the file and you can shove local file where remote is
expected or vice versa... Think about it:
$ mkdir https:
$ echo test https://mail.google.com
$ cat https://mail.google.com
test
Oops?
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
On Sat, Jan 9, 2010 at 2:44 AM, Victor Khimenko k...@google.com wrote:
On Sat, Jan 9, 2010 at 6:08 AM, Antoine Labour pi...@google.com wrote:
How about:
int fd = open(file_or_url, O_RDONLY);
if (fd = 0) {
close(fd);
OpenLocalFile(file_or_url);
} else {
OpenURL(file_or_url);
}
Security risk. It's fine for interactive work (eve then it's risky), but
when script opens the file and you can shove local file where remote is
expected or vice versa... Think about it:
$ mkdir https:
$ echo test https://mail.google.com
$ cat https://mail.google.com
test
Oops?
I'm not sure I understand the security risk... If an attacker is able to
write files on my disk I have a lot more things to worry about than my
browser spoofing urls.
In any case you can always OpenURL(string(file://) +
urlencode(file_or_url)) instead of OpenLocalFile
Antoine
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
On Sat, Jan 9, 2010 at 2:55 PM, Antoine Labour pi...@google.com wrote: I'm not sure I understand the security risk... If an attacker is able to write files on my disk I have a lot more things to worry about than my browser spoofing urls. Are you sure? The idea is the same as with $PATH attack. Sure, some systems don't even need . in PATH to call programs from current dir by default, but it does make it good idea. In any case you can always OpenURL(string(file://) + urlencode(file_or_url)) instead of OpenLocalFile What will this change? There are sad but fundamental truth about POSIX filenames: ANY string without embedded NUL characters can be valid filename. There are some limitations (MAX_PATH, max number of slashes in some systems, etc), but they are minor. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
Bash won't let me do this: $ mkdir https: mkdir: cannot create directory `https:': No such file or directory $ mkdir https: mkdir: cannot create directory `https:': No such file or director 2010/1/9 Victor Khimenko k...@google.com On Sat, Jan 9, 2010 at 2:55 PM, Antoine Labour pi...@google.com wrote: I'm not sure I understand the security risk... If an attacker is able to write files on my disk I have a lot more things to worry about than my browser spoofing urls. Are you sure? The idea is the same as with $PATH attack. Sure, some systems don't even need . in PATH to call programs from current dir by default, but it does make it good idea. In any case you can always OpenURL(string(file://) + urlencode(file_or_url)) instead of OpenLocalFile What will this change? There are sad but fundamental truth about POSIX filenames: ANY string without embedded NUL characters can be valid filename. There are some limitations (MAX_PATH, max number of slashes in some systems, etc), but they are minor. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
What OS is it? What FS ? I've checked with GHardy - everything works just fine. You can create filenames with :, , , etc. Anything except / but then it's compensated by the fact that duplicated slashes are ignored. Cygwin works too (starting from version 1.7 where support for POSIX FS namespace was added) even if it's pretty irrelevant to Chrome discussion... On Sat, Jan 9, 2010 at 5:28 PM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Bash won't let me do this: $ mkdir https: mkdir: cannot create directory `https:': No such file or directory $ mkdir https: mkdir: cannot create directory `https:': No such file or director 2010/1/9 Victor Khimenko k...@google.com On Sat, Jan 9, 2010 at 2:55 PM, Antoine Labour pi...@google.com wrote: I'm not sure I understand the security risk... If an attacker is able to write files on my disk I have a lot more things to worry about than my browser spoofing urls. Are you sure? The idea is the same as with $PATH attack. Sure, some systems don't even need . in PATH to call programs from current dir by default, but it does make it good idea. In any case you can always OpenURL(string(file://) + urlencode(file_or_url)) instead of OpenLocalFile What will this change? There are sad but fundamental truth about POSIX filenames: ANY string without embedded NUL characters can be valid filename. There are some limitations (MAX_PATH, max number of slashes in some systems, etc), but they are minor. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
Actually it was Cygwin on Windows Vista (GNU bash, version 3.2.49(22)-release (i686-pc-cygwin) Copyright (C) 2007 Free Software Foundation, Inc.). However this isn't very important with regards to the point you're trying to make. I was just curious. 2010/1/9 Victor Khimenko k...@google.com What OS is it? What FS ? I've checked with GHardy - everything works just fine. You can create filenames with :, , , etc. Anything except / but then it's compensated by the fact that duplicated slashes are ignored. Cygwin works too (starting from version 1.7 where support for POSIX FS namespace was added) even if it's pretty irrelevant to Chrome discussion... On Sat, Jan 9, 2010 at 5:28 PM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Bash won't let me do this: $ mkdir https: mkdir: cannot create directory `https:': No such file or directory $ mkdir https: mkdir: cannot create directory `https:': No such file or director 2010/1/9 Victor Khimenko k...@google.com On Sat, Jan 9, 2010 at 2:55 PM, Antoine Labour pi...@google.com wrote: I'm not sure I understand the security risk... If an attacker is able to write files on my disk I have a lot more things to worry about than my browser spoofing urls. Are you sure? The idea is the same as with $PATH attack. Sure, some systems don't even need . in PATH to call programs from current dir by default, but it does make it good idea. In any case you can always OpenURL(string(file://) + urlencode(file_or_url)) instead of OpenLocalFile What will this change? There are sad but fundamental truth about POSIX filenames: ANY string without embedded NUL characters can be valid filename. There are some limitations (MAX_PATH, max number of slashes in some systems, etc), but they are minor. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Pierre. -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
CygWin is not POSIX system. It tries to emulate POSIX as much as feasible but version 1.5, for example, does not even use POSIX filesystem namespace! Anyway I've checked: latest stable version (1.7.1-1) works just fine here. You can create directory http: - but it'll look really funny in Explorer and other Windows-native programs (CygWin can not put this name in Windows-native slot so it creates some surrogate to put there). P.S. There are interesting fact related to specifically colon and MacOS. Classic MacOS uses colon as delimeter and you can use slash in filename. when they used POSIX-compliat kernel they needed some way to resolve thus collision. The solution was simple and elegant: they swapped colon and slash - so if you'll create http: directory old MacOS 9 program will see http/ directory. Thus you can create file which looks as http://google.com; for unix-programs and for MacOS programs (even if it'll be two different files). On Sun, Jan 10, 2010 at 12:45 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Actually it was Cygwin on Windows Vista (GNU bash, version 3.2.49(22)-release (i686-pc-cygwin) Copyright (C) 2007 Free Software Foundation, Inc.). However this isn't very important with regards to the point you're trying to make. I was just curious. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] opening local files with chrome from command line, relative paths
We have http://crbug.com/4436, and the problem is that if you launch chrome index.html (with index.html in the current directory) it will try to navigate to http://index.html/ instead. This behavior is useful for cases like chrome www.google.com, and generally I don't see a good solution to this issue other than WontFix. Other shell launchers are expected to pass a full path I think. explorer.exe behaves in a reverse way (www.google.com fails, index.html succeeds). In firefox both local relative paths and urls without http work. What should we do for Chrome? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
On Fri, Jan 8, 2010 at 5:15 AM, Paweł Hajdan, Jr.
phajdan...@chromium.orgwrote:
We have http://crbug.com/4436, and the problem is that if you launch
chrome index.html (with index.html in the current directory) it will
try to navigate to http://index.html/ instead. This behavior is useful
for cases like chrome www.google.com, and generally I don't see a good
solution to this issue other than WontFix. Other shell launchers are
expected to pass a full path I think.
explorer.exe behaves in a reverse way (www.google.com fails,
index.html succeeds).
In firefox both local relative paths and urls without http work.
What should we do for Chrome?
How about:
int fd = open(file_or_url, O_RDONLY);
if (fd = 0) {
close(fd);
OpenLocalFile(file_or_url);
} else {
OpenURL(file_or_url);
}
Antoine
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
