Re: EACCESS vs ENOENT for nonexistent files-within-files

Re: EACCESS vs ENOENT for nonexistent files-within-files

[Paul Wagland]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

On Wed 15 Sep 2004 01:41:40 PM CEST, Nikita Danilov wrote:
> evilninja writes:
>  > evil@prinz:/tmp$ touch file.txt
>  > evil@prinz:/tmp$ cat file.txt/.htaccess
>  > cat: file.txt/.htaccess: Not a directory
>  > evil@prinz:/tmp$ chmod +x file.txt
>  > evil@prinz:/tmp$ cat file.txt/.htaccess
>  > cat: file.txt/.htaccess: Not a directory
>
> 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.
>
> 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.

I'm sorry to be so blunt on this... but this is just plain dumb. Really. For as
long as I have known, an executable bit on a file means that you can "execute"
that file. Now  you try to say, yeah, that, but as well, it means whether or
not you can access the files attributes?

Seriously. What were you thinking?

Does this mean (for example) that on a sgid file, only the group can see the
attributes? Even if the file is world readable? Does this really make sense?

Here is the rub... you are breaking the rules of "one object - one purpose".
Surely this is not how it is meant to be? On a file, the execute bit is meant
for "can I run this file". On a dir, this bit is for "Can I see inside this
directory". They do not match!

Paul.

[-- Attachment #2: PGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: EACCESS vs ENOENT for nonexistent files-within-files

[Hans Reiser]

Paul Wagland wrote:

>On Wed 15 Sep 2004 01:41:40 PM CEST, Nikita Danilov wrote:
>  
>
>>evilninja writes:
>> > evil@prinz:/tmp$ touch file.txt
>> > evil@prinz:/tmp$ cat file.txt/.htaccess
>> > cat: file.txt/.htaccess: Not a directory
>> > evil@prinz:/tmp$ chmod +x file.txt
>> > evil@prinz:/tmp$ cat file.txt/.htaccess
>> > cat: file.txt/.htaccess: Not a directory
>>
>>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.
>>
>>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.
>>    
>>
>
>I'm sorry to be so blunt on this... but this is just plain dumb. Really. For as
>long as I have known, an executable bit on a file means that you can "execute"
>that file. Now  you try to say, yeah, that, but as well, it means whether or
>not you can access the files attributes?
>
>Seriously. What were you thinking?
>
>Does this mean (for example) that on a sgid file, only the group can see the
>attributes? Even if the file is world readable? Does this really make sense?
>
>Here is the rub... you are breaking the rules of "one object - one purpose".
>Surely this is not how it is meant to be? On a file, the execute bit is meant
>for "can I run this file". On a dir, this bit is for "Can I see inside this
>directory". They do not match!
>
>Paul.
>  
>
Separate bits are needed for the separate purposes.  Nikita, can you 
remind what implementation details delay separating the bits?  I thought 
it was already done, sigh....

Hans

Re: EACCESS vs ENOENT for nonexistent files-within-files

[Paul Wagland]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On Wed 15 Sep 2004 04:04:11 PM CEST, Hans Reiser wrote:

> Paul Wagland wrote:
>
>> Does this mean (for example) that on a sgid file, only the group can see the
>> attributes? Even if the file is world readable? Does this really make sense?
>>
>> Here is the rub... you are breaking the rules of "one object - one purpose".
>> Surely this is not how it is meant to be? On a file, the execute bit 
>> is meant
>> for "can I run this file". On a dir, this bit is for "Can I see inside this
>> directory". They do not match!
>>
> Separate bits are needed for the separate purposes.  Nikita, can you
> remind what implementation details delay separating the bits?  I thought
> it was already done, sigh....

Ah good. At least then it can be considered a bug :-) Then I won't get 
too upset
anymore... ;-)

Cheers,
Paul


[-- Attachment #2: PGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: EACCESS vs ENOENT for nonexistent files-within-files

[Nikita Danilov]

Hans Reiser writes:
 > Paul Wagland wrote:
 > 
 > >On Wed 15 Sep 2004 01:41:40 PM CEST, Nikita Danilov wrote:
 > >  
 > >
 > >>evilninja writes:
 > >> > evil@prinz:/tmp$ touch file.txt
 > >> > evil@prinz:/tmp$ cat file.txt/.htaccess
 > >> > cat: file.txt/.htaccess: Not a directory
 > >> > evil@prinz:/tmp$ chmod +x file.txt
 > >> > evil@prinz:/tmp$ cat file.txt/.htaccess
 > >> > cat: file.txt/.htaccess: Not a directory
 > >>
 > >>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.
 > >>
 > >>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.
 > >>    
 > >>
 > >
 > >I'm sorry to be so blunt on this... but this is just plain dumb. Really. For as
 > >long as I have known, an executable bit on a file means that you can "execute"
 > >that file. Now  you try to say, yeah, that, but as well, it means whether or
 > >not you can access the files attributes?
 > >
 > >Seriously. What were you thinking?
 > >
 > >Does this mean (for example) that on a sgid file, only the group can see the
 > >attributes? Even if the file is world readable? Does this really make sense?
 > >
 > >Here is the rub... you are breaking the rules of "one object - one purpose".
 > >Surely this is not how it is meant to be? On a file, the execute bit is meant
 > >for "can I run this file". On a dir, this bit is for "Can I see inside this
 > >directory". They do not match!
 > >
 > >Paul.
 > >  
 > >
 > Separate bits are needed for the separate purposes.  Nikita, can you 
 > remind what implementation details delay separating the bits?  I thought 
 > it was already done, sigh....

The only patch that I know about is MAY_LOOKUP one that I mentioned in
other response. It basically always allowed ->lookup() to be called on a
regular file. This allowes to cope with the most frequent complaint "I
cannot access /etc/passwd/metas/uid!", but this is only sufficient for
pseudo files within regular files. For general situation when objects
behave as both regular and directory, _and_ we want DAC on them,
separate bits are needed indeed. I see several possibilities for this:

    - implement this as reiser4 feature: keep additional bits in
      stat-data and cache them in reiser4 specific portion of inode. 

    - implement this as a generic feature: cache additional bits in
      inode->i_mode (extended appropriately). This requires changing
      generic VFS permission checks and all file systems.

Both approaches still requires modifying all user-level tools that show
or copy permissions (ls, GUI file managers, tar, cpio, cp)

As I had more than one occasion to note, releasing file system into user
land that can silently drop DAC bits (and this is what unmodified cp and
tar will do) is very dangerous enterprise. In the time being, sharing +x
for lookup and exec seems to be the only plausible solution. But, hey!
Who am I to dwell into these matters at this point?

 > 
 > Hans

Nikita.

Re: EACCESS vs ENOENT for nonexistent files-within-files

[Nikita Danilov]

Paul Wagland writes:
 > On Wed 15 Sep 2004 01:41:40 PM CEST, Nikita Danilov wrote:
 > > evilninja writes:
 > >  > evil@prinz:/tmp$ touch file.txt
 > >  > evil@prinz:/tmp$ cat file.txt/.htaccess
 > >  > cat: file.txt/.htaccess: Not a directory
 > >  > evil@prinz:/tmp$ chmod +x file.txt
 > >  > evil@prinz:/tmp$ cat file.txt/.htaccess
 > >  > cat: file.txt/.htaccess: Not a directory
 > >
 > > 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.
 > >
 > > 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.
 > 
 > I'm sorry to be so blunt on this... but this is just plain dumb. Really. For as
 > long as I have known, an executable bit on a file means that you can "execute"
 > that file. Now  you try to say, yeah, that, but as well, it means whether or
 > not you can access the files attributes?

The real problem is that in reiser4 regular files and directories are
indistinguishable by design. There can be subobjects within "regular"
file and one can do read("directory"), or, even, execve("directory") to
one's heart content.
  
 > 
 > Seriously. What were you thinking?

"I am thinking" as you style it, that in "foo/bar" path, "foo" is a
directory, and +x bit controls whether lookups are allowed on it. How in
your opinion lookup permission should be controlled instead?

In traditional UNIX different sets of operations were applicable to the
regular files and directories: for any given object either lookup or
exec were applicable by never both. So, the same bit in permissions mask
was used to control lookup and exec.

Now, we have a situation where there are objects for which both lookup
and exec are implemented. What can be done here short of abandoning
whole UNIX security model, adding new bits, rewriting large fractions of
user space and kernel code, etc.? Current reiser4 behavior is a
reasonable compromise. Other alternatives include 

   . "always allow lookup, use +x to control exec" (MAY_LOOKUP patch)

   . "always allow exec, use +x to control lookup" 

 > 
 > Does this mean (for example) that on a sgid file, only the group can see the

What +s bit has to do with anything mentioned so far?

 > 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.

 > 
 > Here is the rub... you are breaking the rules of "one object - one purpose".
 > Surely this is not how it is meant to be? On a file, the execute bit is meant

Surely equivalence of files and directories (and attributes) is exactly
how it is meant to be in reiser4. Ask Hans as to why.

 > for "can I run this file". On a dir, this bit is for "Can I see inside this
 > directory". They do not match!

And given that in reiser4 there is no difference between (regular) file
and directory this gives...?

There is 1000+ messagesful thread about these issues on LKML, from where
you can l

Re: EACCESS vs ENOENT for nonexistent files-within-files

[daniel.poelzleithner]

-----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

[Hans Reiser]

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

[Toby Dickenson]

On Wednesday 15 September 2004 15:45, Nikita Danilov wrote:

> The real problem is that in reiser4 regular files and directories are
> indistinguishable by design. 

Indistinguishable?

Ive been following the reiser4 message so far and felt comfortable with 
performing directory-like operations on files. But I think this is the first 
mention that files and directories would be *indistinguisable*. What does 
'ls' show, and how?

> and one can do read("directory"), or, even, execve("directory") to
> one's heart content.

I think thats the first mention of performing file operations on a directory.

-- 
Toby Dickenson

Re: EACCESS vs ENOENT for nonexistent files-within-files

[Perry Kundert]

On Thu, 16 Sep 2004 20:55:38 +0100, Toby Dickenson
<tdickenson@geminidataloggers.com> wrote:
> On Wednesday 15 September 2004 15:45, Nikita Danilov wrote:
>
> > The real problem is that in reiser4 regular files and directories are
> > indistinguishable by design.
>
> Indistinguishable?
>
> Ive been following the reiser4 message so far and felt comfortable with
> performing directory-like operations on files. But I think this is the first
> mention that files and directories would be *indistinguisable*. What does
> 'ls' show, and how?


    I would agree.  Clearly, in reiser4 'files' can (optionally) have
a 'directory' personality, presumably containing metadata associated
with the file (and hence, being accessible with the same level of
access as the file itself).  If you want to have data that is NOT
accessed with the same level of permissions as the file -- then don't
put it "in" the file's 'directory'!

    The obverse would be true of a 'directory' with metadata; This
directory's metadata would be accessible with the same level of
permission as the directory.

    If the primary "personality" of a file and directory are
indistinguishable (which I don't believe is true), then every
filesystem file/directory will indeed need two sets of permissions;
one for accessing it as a "file", and one for accessing it as a
"directory".  This is, of course, ridiculous, and will break
everything worse than the concept of file's w/ a directory of metadata
ever would, on its own.

--
    -pjk

> --
> Toby Dickenson
>

EACCESS vs ENOENT for nonexistent files-within-files

[Joe Orton]

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.

Regards,

joe

Re: EACCESS vs ENOENT for nonexistent files-within-files

[Wayne Scott]

From: Joe Orton <jorton@redhat.com>
> 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

[Michael Weissenbacher]

> 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

[Alex Zarochentsev]

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.c	Tue 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

[Joe Orton]

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

[Nikita Danilov]

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

[evilninja]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nikita Danilov wrote:
>
> 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.

at least on ext3 and nfs3 i have this:

evil@prinz:/tmp$ touch file.txt
evil@prinz:/tmp$ cat file.txt/.htaccess
cat: file.txt/.htaccess: Not a directory
evil@prinz:/tmp$ chmod +x file.txt
evil@prinz:/tmp$ cat file.txt/.htaccess
cat: file.txt/.htaccess: Not a directory

...which sounds *a bit* more reasonable than "permission denied", but
   "cat: file.txt/: Not a directory"
or
   "cat: file.txt/.htaccess: No such file or directory"

would make even more sense IMHO.

Christian.
- --
BOFH excuse #290:

The CPU has shifted, and become decentralized.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBSB+lC/PVm5+NVoYRAvslAJwLMd7VJlOOIJhkZmYMetspLeWYzQCgsUli
SFgoAG3eMrHn1URscHeoGZM=
=yFbW
-----END PGP SIGNATURE-----

Re: EACCESS vs ENOENT for nonexistent files-within-files

[Nikita Danilov]

evilninja writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1

Hello, Christian evilninja :)

 > 
 > Nikita Danilov wrote:
 > >
 > > 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.
 > 
 > at least on ext3 and nfs3 i have this:
 > 
 > evil@prinz:/tmp$ touch file.txt
 > evil@prinz:/tmp$ cat file.txt/.htaccess
 > cat: file.txt/.htaccess: Not a directory
 > evil@prinz:/tmp$ chmod +x file.txt
 > evil@prinz:/tmp$ cat file.txt/.htaccess
 > cat: file.txt/.htaccess: Not a directory

But in reiser4 file.txt _is_ a directory. That's the whole point: it
contains other objects inside.

 > 
 > ...which sounds *a bit* more reasonable than "permission denied", but
 >    "cat: file.txt/: Not a directory"
 > or
 >    "cat: file.txt/.htaccess: No such file or directory"
 > 
 > would make even more sense IMHO.

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.

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.

 > 
 > Christian.

Nikita.

 > - --
 > BOFH excuse #290:
 > 
 > The CPU has shifted, and become decentralized.
 > -----BEGIN PGP SIGNATURE-----
 > Version: GnuPG v1.2.5 (GNU/Linux)
 > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
 > 
 > iD8DBQFBSB+lC/PVm5+NVoYRAvslAJwLMd7VJlOOIJhkZmYMetspLeWYzQCgsUli
 > SFgoAG3eMrHn1URscHeoGZM=
 > =yFbW
 > -----END PGP SIGNATURE-----

Re: EACCESS vs ENOENT for nonexistent files-within-files

[evilninja]

-----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

[Alex Zarochentsev]

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.