Re: EACCESS vs ENOENT for nonexistent files-within-files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nikita Danilov wrote: | attributes? Even if the file is world readable? Does this really make sense? | | To make things clear: I have described in my message how things actually | do work in reiser4, so I don't see the point of your questions. If you | think reiser4 semantics is wrong (I am not happy with it too, by the | way), propose to Namesys something better. I would suggest to allow lookups when the user can read the file. The x bit should remain for exec on file objects, because console would be pain when every file must have a exec bits to access meta data. When the user can read a file, i don't think that the meta data can be security risk, he has already access to the file. And therefor not write access to file/metas without +w. No, its not perfect, but i think more unix like than +x for lookups on files. regards ~ Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBSGqZy/mkIQp7AD0RAotiAKCTmffDuqsYj2KGkRtaE+fitU2e/QCfXS5t qZHo5nFd0m1wJFw7MNhDTX8= =Ejyo -END PGP SIGNATURE-
Re: EACCESS vs ENOENT for nonexistent files-within-files
daniel.poelzleithner wrote: Nikita Danilov wrote: | attributes? Even if the file is world readable? Does this really make sense? | | To make things clear: I have described in my message how things actually | do work in reiser4, so I don't see the point of your questions. If you | think reiser4 semantics is wrong (I am not happy with it too, by the | way), propose to Namesys something better. I would suggest to allow lookups when the user can read the file. The x bit should remain for exec on file objects, because console would be pain when every file must have a exec bits to access meta data. When the user can read a file, i don't think that the meta data can be security risk, he has already access to the file. And therefor not write access to file/metas without +w. No, its not perfect, but i think more unix like than +x for lookups on files.] I like this for access to the builtin metafiles (whose permissions should normally be determined not individually but pased on the plugin and its permissions, but what about files within file-directories? For them I think we need to allow sys_reiser4 to change the bits independently, and for apps that don't know how to distinguish the 2 bits, oh well, change one change the other. What are your thoughts? regards ~ Daniel
Re: EACCESS vs ENOENT for nonexistent files-within-files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nikita Danilov wrote: evilninja writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Christian evilninja :) um, yes, it just sticks ;-) But in reiser4 file.txt _is_ a directory. That's the whole point: it contains other objects inside. [...] This is very simple: do be able to do a lookup one needs +x bit. No +x bit--no lookup. No lookup---impossible to determine exists .htaccess or not. ok, so things will be different when i'll try reiser4 on my box. Permission bits determine what operations are possible on object. Letting user to know that .htaccess doesn't exist while permission bits on parent explicitly disable lookups is a security hole. yes, i think i got i now. thanks for the explanation. Christian. - -- BOFH excuse #65: system needs to be rebooted -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBSNerC/PVm5+NVoYRAuLsAJ99JCbKQ0ebl9xRPwwYK/un9OKRtgCg3nOu tlYw+GkQWwO2Kfk1pEVlivE= =5iJg -END PGP SIGNATURE-
Re: EACCESS vs ENOENT for nonexistent files-within-files
From: Joe Orton [EMAIL PROTECTED] Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. Thank you. I was just tracking down a similar problem with BitKeeper that is explained by this bug. You saved me some work. -Wayne
Re: EACCESS vs ENOENT for nonexistent files-within-files
Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. Can someone explain the justification behind reiser4's behaviour? httpd's assumption does not seem unreasonable, and EACCES seems to make little sense for this error case. i think the problem would be solved by mounting the partition with the nopseudos option. of course, this is not the long-term solution. regards, michael
Re: EACCESS vs ENOENT for nonexistent files-within-files
On Mon, Sep 13, 2004 at 03:06:37PM +0100, Joe Orton wrote:
Hi, we had a bug report that Apache httpd logs a spurious error for
every file served from a reiser4 filesystem, because httpd assumes that
/path/to/file/.htaccess (where /path/to/file is a normal file) returns
ENOENT or ENOTDIR, but reiser4 returns EACCES in this case.
Can someone explain the justification behind reiser4's behaviour?
httpd's assumption does not seem unreasonable, and EACCES seems to make
little sense for this error case.
It is because open(name, O_DIRECTORY) is successful for regular files in
reiser4. Once it succedes, Apache2 thinks that is a directory and tries to
open .htaccess under it. It does not matter what error code is receives there,
the problem is that apache2 has decided that the file is a directory.
There are two solutions:
1) mount reiser4 partition with nopseudo mount option. it makes /metas/* files
unaccessible.
2) apply the patch:
= fs/namei.c 1.104 vs edited =
--- 1.104/fs/namei.cTue Aug 10 16:59:38 2004
+++ edited/fs/namei.c Sun Sep 12 11:00:18 2004
@@ -816,7 +816,7 @@
break;
if (lookup_flags LOOKUP_DIRECTORY) {
err = -ENOTDIR;
- if (!inode-i_op || !inode-i_op-lookup)
+ if (!S_ISDIR(inode-i_mode))
break;
}
goto return_base;
===
Regards,
joe
--
Alex.
Re: EACCESS vs ENOENT for nonexistent files-within-files
On Mon, Sep 13, 2004 at 08:13:26PM +0400, Alex Zarochentsev wrote: On Mon, Sep 13, 2004 at 03:06:37PM +0100, Joe Orton wrote: Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. Can someone explain the justification behind reiser4's behaviour? httpd's assumption does not seem unreasonable, and EACCES seems to make little sense for this error case. It is because open(name, O_DIRECTORY) is successful for regular files in reiser4. Once it succedes, Apache2 thinks that is a directory and tries to open .htaccess under it. I don't think that has anything to do with it. It's a simple open() without O_DIRECTORY which is failing with EACCES. The reporter confirmed this with the simplest of tests: $ touch newfile.txt $ cat newfile.txt/.htaccess cat: newfile.txt/.htaccess: Permission denied this is the behaviour I'm trying to find the justification for. There are two solutions: 1) mount reiser4 partition with nopseudo mount option. it makes /metas/* files unaccessible. If this is broken by default, our users will continue to complain, so that doesn't really help. 2) apply the patch: OK, does this mean you do consider this a bug in reiser4 which will be fixed in future releases, then? Regards, joe
Re: EACCESS vs ENOENT for nonexistent files-within-files
Joe Orton writes: On Mon, Sep 13, 2004 at 08:13:26PM +0400, Alex Zarochentsev wrote: On Mon, Sep 13, 2004 at 03:06:37PM +0100, Joe Orton wrote: Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. Can someone explain the justification behind reiser4's behaviour? httpd's assumption does not seem unreasonable, and EACCES seems to make little sense for this error case. It is because open(name, O_DIRECTORY) is successful for regular files in reiser4. Once it succedes, Apache2 thinks that is a directory and tries to open .htaccess under it. I don't think that has anything to do with it. It's a simple open() without O_DIRECTORY which is failing with EACCES. The reporter confirmed this with the simplest of tests: The only reason Apache is trying to access regular/.htaccess is because previous open(regular, O_DIRECTORY) returned success. $ touch newfile.txt $ cat newfile.txt/.htaccess cat: newfile.txt/.htaccess: Permission denied this is the behaviour I'm trying to find the justification for. If newfile.txt has no +x bit set, then justification is obvious: UNIX requires +x bit for lookup, and EACCES is returned when trying to lookup anything in a directory (or, in this case, a regular file) without +x bit: $ mkdir zzz $ chmod a-x zzz $ cat zzz/.htaccess cat: zzz/.htaccess: Permission denied This is how things worked for almost 30 years. If you observe EACCES on the file with +x bit---this is unknown bug and test-case is most welcome. There are two solutions: 1) mount reiser4 partition with nopseudo mount option. it makes /metas/* files unaccessible. If this is broken by default, our users will continue to complain, so that doesn't really help. 2) apply the patch: OK, does this mean you do consider this a bug in reiser4 which will be fixed in future releases, then? Regards, joe Nikita.
Re: EACCESS vs ENOENT for nonexistent files-within-files
On Mon, Sep 13, 2004 at 07:52:55PM +0100, Joe Orton wrote: On Mon, Sep 13, 2004 at 08:13:26PM +0400, Alex Zarochentsev wrote: On Mon, Sep 13, 2004 at 03:06:37PM +0100, Joe Orton wrote: Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. what does the user get in the browser? Can someone explain the justification behind reiser4's behaviour? httpd's assumption does not seem unreasonable, and EACCES seems to make little sense for this error case. It is because open(name, O_DIRECTORY) is successful for regular files in reiser4. Once it succedes, Apache2 thinks that is a directory and tries to open .htaccess under it. I don't think that has anything to do with it. It's a simple open() without O_DIRECTORY which is failing with EACCES. The reporter confirmed this with the simplest of tests: $ touch newfile.txt $ cat newfile.txt/.htaccess cat: newfile.txt/.htaccess: Permission denied But what is the reason why apache2 looks at regular file/.htaccess ? can you ask the user to add execute permitions (just for test) to the file and see would apache2 work with the file. this is the behaviour I'm trying to find the justification for. There are two solutions: 1) mount reiser4 partition with nopseudo mount option. it makes /metas/* files unaccessible. If this is broken by default, our users will continue to complain, so that doesn't really help. 2) apply the patch: OK, does this mean you do consider this a bug in reiser4 which will be fixed in future releases, then? it requires Linux VFS changes, the changes are being discussed in LKML still. Regards, joe -- Alex.
