metas Permission Denied

metas Permission Denied

[Boyd Waters]

Perhaps this is obvious, but why am I getting "Permission Denied" 
errors on the "metas" pseudo for some -- but not all -- of the files on 
a reiser4 volume?

(doing this as root)

~ boyd

Boyd Waters
National Radio Astronomy Observatory
Socorro, New Mexico

Re: metas Permission Denied

[Nikita Danilov]

Boyd Waters writes:
 > Perhaps this is obvious, but why am I getting "Permission Denied" 
 > errors on the "metas" pseudo for some -- but not all -- of the files on 
 > a reiser4 volume?
 > 
 > (doing this as root)

Can you provide more details?

 > 
 > ~ boyd
 > 
 > Boyd Waters
 > National Radio Astronomy Observatory
 > Socorro, New Mexico
 > 

Nikita.

Re: metas Permission Denied

[Boyd Waters]

On Apr 29, 2004, at 1:56 AM, Nikita Danilov wrote:

> Boyd Waters writes:
>> Perhaps this is obvious, but why am I getting "Permission Denied"
>> errors on the "metas" pseudo for some -- but not all -- of the files 
>> on
>> a reiser4 volume?
>>
>> (doing this as root)
>
> Can you provide more details?

Sorry, I know I was not very specific, but I thought perhaps there was 
a quick obvious answer.

Here is a simple case: a directory that holds three files; I can see 
the metas dir on one of the files and not on another one.

It's like this all over this file system. I cannot predict which files 
will let me look at their "metas" pseudo. All directories seem to 
support the metas pseudo consistently.



> lurch __ # ls backup/
> backup.sh*  fsplit*  fsplit.c

> lurch __ # ls backup/fsplit.c/metas
> ls: backup/fsplit.c/metas: Permission denied

> lurch __ # ls backup/fsplit/metas
> bmap  items  locality  nlink  pagecache/  pseudo   rwx   uid
> gid   key    new       oid    plugin/     readdir  size

> lurch __ # file backup/fsplit.c
> backup/fsplit.c: ASCII C program text

> lurch __ # stat backup/fsplit.c
>   File: `backup/fsplit.c'
>   Size: 4794            Blocks: 10         IO Block: 65536  regular 
> file
> Device: 701h/1793d      Inode: 265994      Links: 1
> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    
> root)
> Access: 2004-04-29 08:57:56.765859214 -0600
> Modify: 2004-01-19 15:04:51.000000000 -0700
> Change: 2004-04-23 00:16:43.922694256 -0600

> lurch __ # file backup/fsplit
> backup/fsplit: ELF 32-bit LSB executable, Intel 80386, version 1 
> (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), 
> not stripped

> lurch __ # stat backup/fsplit
>   File: `backup/fsplit'
>   Size: 11191           Blocks: 22         IO Block: 65536  regular 
> file
> Device: 701h/1793d      Inode: 265992      Links: 1
> Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    
> root)
> Access: 2004-04-29 08:58:05.118418514 -0600
> Modify: 2004-01-19 15:05:16.000000000 -0700
> Change: 2004-04-23 00:16:43.915696302 -0600


> # uname -a
> Linux lurch 2.6.5-Redeiser4 #3 Fri Apr 23 17:55:28 MDT 2004 i686 AMD 
> Duron(tm) Processor AuthenticAMD GNU/Linux

using Redeeman's patches.

~ boyd

Re: metas Permission Denied

[Nikita Danilov]

Boyd Waters writes:
 > 
 > On Apr 29, 2004, at 1:56 AM, Nikita Danilov wrote:
 > 
 > > Boyd Waters writes:
 > >> Perhaps this is obvious, but why am I getting "Permission Denied"
 > >> errors on the "metas" pseudo for some -- but not all -- of the files 
 > >> on
 > >> a reiser4 volume?
 > >>
 > >> (doing this as root)
 > >
 > > Can you provide more details?
 > 
 > Sorry, I know I was not very specific, but I thought perhaps there was 
 > a quick obvious answer.
 > 
 > Here is a simple case: a directory that holds three files; I can see 
 > the metas dir on one of the files and not on another one.
 > 
 > It's like this all over this file system. I cannot predict which files 
 > will let me look at their "metas" pseudo. All directories seem to 
 > support the metas pseudo consistently.
 > 
 > 
 > 
 > > lurch __ # ls backup/
 > > backup.sh*  fsplit*  fsplit.c
 > 
 > > lurch __ # ls backup/fsplit.c/metas
 > > ls: backup/fsplit.c/metas: Permission denied

chmod u+rx backup/fsplit.c

"x" bit is necessary for lookups, and "r" bit---for readdir.

Nikita.

Re: metas Permission Denied

[Hans Reiser]

Nikita Danilov wrote:

>Boyd Waters writes:
> > 
> > On Apr 29, 2004, at 1:56 AM, Nikita Danilov wrote:
> > 
> > > Boyd Waters writes:
> > >> Perhaps this is obvious, but why am I getting "Permission Denied"
> > >> errors on the "metas" pseudo for some -- but not all -- of the files 
> > >> on
> > >> a reiser4 volume?
> > >>
> > >> (doing this as root)
> > >
> > > Can you provide more details?
> > 
> > Sorry, I know I was not very specific, but I thought perhaps there was 
> > a quick obvious answer.
> > 
> > Here is a simple case: a directory that holds three files; I can see 
> > the metas dir on one of the files and not on another one.
> > 
> > It's like this all over this file system. I cannot predict which files 
> > will let me look at their "metas" pseudo. All directories seem to 
> > support the metas pseudo consistently.
> > 
> > 
> > 
> > > lurch __ # ls backup/
> > > backup.sh*  fsplit*  fsplit.c
> > 
> > > lurch __ # ls backup/fsplit.c/metas
> > > ls: backup/fsplit.c/metas: Permission denied
>
>chmod u+rx backup/fsplit.c
>
>"x" bit is necessary for lookups, and "r" bit---for readdir.
>
>Nikita.
>
>
>
>  
>
Didn't someone send us a fix for this problem which separated the 
permissions?  Remeind me what the problem with that was.....?

Re: metas Permission Denied

[Boyd Waters]

On Apr 29, 2004, at 10:14 AM, Hans Reiser wrote:

> Nikita Danilov wrote:
>
>> "x" bit is necessary for lookups, and "r" bit---for readdir.
>>
> Didn't someone send us a fix for this problem which separated the 
> permissions?  Remeind me what the problem with that was.....?
>


I must agree that the "r" bit should be sufficient to view the 
pseudo-subdirs on a file, no matter what the "x" bit setting.

The traditional semantics of the 'x' bit on directories is awful; 
Banyan Vines had an explicit 'scan' attrib on directories for this, and 
I believe Windows has something as well. Some way to express 
"permission to descend into this directory" as opposed to "permission 
to readdir() this directory". Something that is NOT the 'x' bit. Would 
be perhaps too awful or impossible to add to POSIX, I don't know.

In any event, the semantics of the 'x' bit on FILES is very clear: this 
is an executable file.

You run into trouble when you want to make a file look like a 
directory, but the thing IS_A file -- and therefore the "file-x-bit" 
semantics should shadow any "dir-x-bit" behavior.

The 'read' bit should let you look at the "sub-dirs" of a file!

Thanks!

~ boyd

Boyd Waters
National Radio Astronomy Observatory
Socorro, New Mexico

Re: metas Permission Denied

[Grant Miner]

> The traditional semantics of the 'x' bit on directories is awful; Banyan 
> Vines had an explicit 'scan' attrib on directories for this, and I 
> believe Windows has something as well. Some way to express "permission 
> to descend into this directory" as opposed to "permission to readdir() 
> this directory". Something that is NOT the 'x' bit. Would be perhaps too 
> awful or impossible to add to POSIX, I don't know.

In Windows they also just have a bit for "traverse directory / execute 
file" and another bit for "list directory / read data".

However, the default policy makes the OS ignore the traverse/execute for 
directory traversal (but not file execution) entirely!  This might be 
the way to go in Linux as well.

Re: metas Permission Denied

[Boyd Waters]

On Apr 29, 2004, at 2:52 PM, Grant Miner wrote:

> In Windows they also just have a bit for "traverse directory / execute 
> file" and another bit for "list directory / read data".
>
> However, the default policy makes the OS ignore the traverse/execute 
> for directory traversal (but not file execution) entirely!  This might 
> be the way to go in Linux as well.

Yow! Thanks for the info...

No, I use the directory-traversal (without read) semantics all the 
time, *ignoring* this bit would be a Bad Thing for a multi-user system 
to do.

~ boyd

Re: metas Permission Denied

[Hans Reiser]

Grant Miner wrote:

>
>> The traditional semantics of the 'x' bit on directories is awful; 
>> Banyan Vines had an explicit 'scan' attrib on directories for this, 
>> and I believe Windows has something as well. Some way to express 
>> "permission to descend into this directory" as opposed to "permission 
>> to readdir() this directory". Something that is NOT the 'x' bit. 
>> Would be perhaps too awful or impossible to add to POSIX, I don't know.
>
>
> In Windows they also just have a bit for "traverse directory / execute 
> file" and another bit for "list directory / read data".
>
> However, the default policy makes the OS ignore the traverse/execute 
> for directory traversal (but not file execution) entirely!

I don't understand the sentence above.  Is the bit only used by the 
nondefault policies?

>   This might be the way to go in Linux as well.
>
>

Re: metas Permission Denied

[Grant Miner]

> 
> I don't understand the sentence above.  Is the bit only used by the 
> nondefault policies?
> 

Sort of.  The bit always applies for execute.  The bit never applies for 
traverse directory, unless the default policy is changed.

Re: metas Permission Denied

[Valdis.Kletnieks]

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

On Thu, 29 Apr 2004 19:59:22 +0400, Nikita Danilov said:

> chmod u+rx backup/fsplit.c
> 
> "x" bit is necessary for lookups, and "r" bit---for readdir.

This is going to be *such* a non-starter - there's many decades of
"C files are mode 644 and executables are 755" tradition that this
will fly against.  What this basically implies is that the 'execute'
bit is useless, because it's being overloaded to mean both "the file
is executable" and "you can peek at the metadata".

% cd /tmp
% cat > foo.sh
echo foo
% ./foo.sh
-bash: ./foo.sh: Permission denied
% chmod +x ./foo.sh
% ./foo.sh
foo

Do you really intend to break those semantics??

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: metas Permission Denied

[Nikita Danilov]

Valdis.Kletnieks@vt.edu writes:
 > On Thu, 29 Apr 2004 19:59:22 +0400, Nikita Danilov said:
 > 
 > > chmod u+rx backup/fsplit.c
 > > 
 > > "x" bit is necessary for lookups, and "r" bit---for readdir.
 > 
 > This is going to be *such* a non-starter - there's many decades of
 > "C files are mode 644 and executables are 755" tradition that this
 > will fly against.  What this basically implies is that the 'execute'

Eh? What I described is precisely decades old meaning of rwx bits for
directories.

Problem is that we have to fit objects that are both regular files and
directories into access control scheme that wasn't designed for such a
mix. I don't see better solution short of inventing new bit(s).

 > bit is useless, because it's being overloaded to mean both "the file
 > is executable" and "you can peek at the metadata".
 > 
 > % cd /tmp
 > % cat > foo.sh
 > echo foo
 > % ./foo.sh
 > -bash: ./foo.sh: Permission denied
 > % chmod +x ./foo.sh
 > % ./foo.sh
 > foo
 > 
 > Do you really intend to break those semantics??

Nikita.

Re: metas Permission Denied

[Chris Mason]

On Thu, 2004-04-29 at 12:22, Nikita Danilov wrote:
> Valdis.Kletnieks@vt.edu writes:
>  > On Thu, 29 Apr 2004 19:59:22 +0400, Nikita Danilov said:
>  > 
>  > > chmod u+rx backup/fsplit.c
>  > > 
>  > > "x" bit is necessary for lookups, and "r" bit---for readdir.
>  > 
>  > This is going to be *such* a non-starter - there's many decades of
>  > "C files are mode 644 and executables are 755" tradition that this
>  > will fly against.  What this basically implies is that the 'execute'
> 
> Eh? What I described is precisely decades old meaning of rwx bits for
> directories.
> 
> Problem is that we have to fit objects that are both regular files and
> directories into access control scheme that wasn't designed for such a
> mix. I don't see better solution short of inventing new bit(s).

Please forgive me for jumping into the end of a thread without reading
the whole thing, but it seems like the r bit should be sufficient here. 
If you can read the file, you should be able to read the metas.

x should be for execution of the file...

-chris

Re: metas Permission Denied

[Hans Reiser]

Chris Mason wrote:

>On Thu, 2004-04-29 at 12:22, Nikita Danilov wrote:
>  
>
>>Valdis.Kletnieks@vt.edu writes:
>> > On Thu, 29 Apr 2004 19:59:22 +0400, Nikita Danilov said:
>> > 
>> > > chmod u+rx backup/fsplit.c
>> > > 
>> > > "x" bit is necessary for lookups, and "r" bit---for readdir.
>> > 
>> > This is going to be *such* a non-starter - there's many decades of
>> > "C files are mode 644 and executables are 755" tradition that this
>> > will fly against.  What this basically implies is that the 'execute'
>>
>>Eh? What I described is precisely decades old meaning of rwx bits for
>>directories.
>>
>>Problem is that we have to fit objects that are both regular files and
>>directories into access control scheme that wasn't designed for such a
>>mix. I don't see better solution short of inventing new bit(s).
>>    
>>
>
>Please forgive me for jumping into the end of a thread without reading
>the whole thing, but it seems like the r bit should be sufficient here. 
>If you can read the file, you should be able to read the metas.
>
>x should be for execution of the file...
>
>-chris
>
>
>
>
>  
>
what if the file/directory contains "real" files which are not metas, 
and it also has a file body?  This is possible in reiser4.

Re: metas Permission Denied

[Chris Mason]

On Fri, 2004-04-30 at 01:19, Hans Reiser wrote:
> Chris Mason wrote:
> 
> >On Thu, 2004-04-29 at 12:22, Nikita Danilov wrote:
> >  
> >
> >>Valdis.Kletnieks@vt.edu writes:
> >> > On Thu, 29 Apr 2004 19:59:22 +0400, Nikita Danilov said:
> >> > 
> >> > > chmod u+rx backup/fsplit.c
> >> > > 
> >> > > "x" bit is necessary for lookups, and "r" bit---for readdir.
> >> > 
> >> > This is going to be *such* a non-starter - there's many decades of
> >> > "C files are mode 644 and executables are 755" tradition that this
> >> > will fly against.  What this basically implies is that the 'execute'
> >>
> >>Eh? What I described is precisely decades old meaning of rwx bits for
> >>directories.
> >>
> >>Problem is that we have to fit objects that are both regular files and
> >>directories into access control scheme that wasn't designed for such a
> >>mix. I don't see better solution short of inventing new bit(s).
> >>    
> >>
> >
> >Please forgive me for jumping into the end of a thread without reading
> >the whole thing, but it seems like the r bit should be sufficient here. 
> >If you can read the file, you should be able to read the metas.
> >
> >x should be for execution of the file...
> >
> what if the file/directory contains "real" files which are not metas, 
> and it also has a file body?  This is possible in reiser4.

Well, that would explain needing the execute bit ;-)

I guess this is a matter of taste, but to me, the metas are really part
of the file.  If you can read the file you should be able to at least
read the listing of metas, for the same reasons that you can read the
file size and atime/mtime etc.  

This could hold true for /somedir/metas as well.

-chris

Re: metas Permission Denied

[Hans Reiser]

Chris Mason wrote:

>On Fri, 2004-04-30 at 01:19, Hans Reiser wrote:
>  
>
>>Chris Mason wrote:
>>
>>    
>>
>>>On Thu, 2004-04-29 at 12:22, Nikita Danilov wrote:
>>> 
>>>
>>>      
>>>
>>>>Valdis.Kletnieks@vt.edu writes:
>>>>        
>>>>
>>>>>On Thu, 29 Apr 2004 19:59:22 +0400, Nikita Danilov said:
>>>>>
>>>>>          
>>>>>
>>>>>>chmod u+rx backup/fsplit.c
>>>>>>
>>>>>>"x" bit is necessary for lookups, and "r" bit---for readdir.
>>>>>>            
>>>>>>
>>>>>This is going to be *such* a non-starter - there's many decades of
>>>>>"C files are mode 644 and executables are 755" tradition that this
>>>>>will fly against.  What this basically implies is that the 'execute'
>>>>>          
>>>>>
>>>>Eh? What I described is precisely decades old meaning of rwx bits for
>>>>directories.
>>>>
>>>>Problem is that we have to fit objects that are both regular files and
>>>>directories into access control scheme that wasn't designed for such a
>>>>mix. I don't see better solution short of inventing new bit(s).
>>>>   
>>>>
>>>>        
>>>>
>>>Please forgive me for jumping into the end of a thread without reading
>>>the whole thing, but it seems like the r bit should be sufficient here. 
>>>If you can read the file, you should be able to read the metas.
>>>
>>>x should be for execution of the file...
>>>
>>>      
>>>
>>what if the file/directory contains "real" files which are not metas, 
>>and it also has a file body?  This is possible in reiser4.
>>    
>>
>
>Well, that would explain needing the execute bit ;-)
>
>I guess this is a matter of taste, but to me, the metas are really part
>of the file.  If you can read the file you should be able to at least
>read the listing of metas, for the same reasons that you can read the
>file size and atime/mtime etc.  
>  
>
Put another way, the metas should by default inherit their read 
permission from the directory(file) they are part of.

>This could hold true for /somedir/metas as well.
>
>-chris
>
>
>
>
>
>
>  
>

Re: metas Permission Denied

[Valdis.Kletnieks]

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

On Thu, 29 Apr 2004 20:22:12 +0400, Nikita Danilov said:
> Eh? What I described is precisely decades old meaning of rwx bits for
> directories.

Exactly.  The problem is that the rwx bits have had other meanings for decades
on "regular files"..

> Problem is that we have to fit objects that are both regular files and
> directories into access control scheme that wasn't designed for such a
> mix. I don't see better solution short of inventing new bit(s).

AIX/370's 'Transparent Computing Facility" had similar issues with "hidden
directories", and HP/UX apparently had "context sensitive directories".  AIX/
370 mostly used it to support transparent usage of binaries across multiple
architectures.  So for instance,

/bin/ls@  was a directory, with an additional flag in the inode saying 'hidden'
(you needed both the trailing @ and the flag).  Then in the directory, you'd
have two or more binaries "i386" "i370" "xa370" for various architectures.

I spent a good chunk of 3 years fighting the resulting brain damage - although
it *mostly* worked OK, the corner cases kept popping up.

Imagine *every* bug you've ever seen that involved confusing the 'stat()'
system call with 'lstat()', and every bug that's ever been caused because of
the blurring of "mount point" and "directory"..  Now imagine that *every file*
on the file system can trigger that sort of bug, not just the relatively small
percentage of files that are mount points or symlinks.....

Trust me - you *really* want to create a new bit, simply to avoid breaking
every program that thinks the old bit has the usual semantics.



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]