Re: RAMFS fixes: file permissions and lseek()

[Dan Jakubiec <dan dot jakubiec at systech dot com>]

Andrew Lunn wrote:

> I don't disagree with this, which is why i accepted the patch. I just
> think it might be better to return 000 so that the application is more
> likely to fail. You then have to take a look at the code and work out
> the implications of the lack of security and what is the application
> trying to do. In your case it is not a problem there is no security,
> but in other cases it might be a big problem....
>
>  
I understand what you're saying.  But I don't think we're obscuring any 
security issues here.  eCos does provide limited permissions support: 
you can read permissions, but you can't change them.  The fix we agreed 
on simply reports the true state of the permissions: all files are 
readable and writeable by everyone. 

The change to 777 actually addresses the very problem you are concerned 
about.  If an application were indeed trying verify the state of file 
security, it would be checking for the *absence* of permissions, not the 
presence.  For example: say the application wanted to make sure that a 
particular file was not readable by group or other.  Previously it would 
see 000 and feel secure.  Now it will see 777 and know that the files 
are not secure.  This might lead the app to failure, but as you observed 
that would be a good thing.

Put another way: with 000 applications that wanted to simply read/write 
would fail, while applications that wanted to protect/restrict would 
falsely succeed.  The fix corrects this.

> Yes, it should. 
>
> How it works is that the code which finds the blocks when performing a
> read will return a null pointer if the block does not exist. If i get
> a null pointer i do a memset to zero. If a get something that is not a
> null pointer i do a memcpy. It is only when you do a write does it
> actually allocate the block. This lazy allocation of blocks is very
> common in filesystems and often used in database systems. Take a look
> at the man page of ndbm.
>
> Having said that, your test case is actually a little different since
> the writes will occur inside the same block since blocks default to
> 256 bytes. The first write will cause the block to the
> allocated. During this allocation the entire block is zero'd.
>
> My test case actually tests writes/reads to different blocks since i
> use 1K reads/writes in my test. If you want to test your scenario
> change the size of buf and buf1 from 1024 to 8 and it should then be
> equivalent to what you said above.
>
>        Andrew
>  
Ahh, I see.  Very clever, thanks.  I'll work those changes back into our 
code base.

--
Dan Jakubiec
Systech Corporation