[ECOS] chmod (crops up on YAFFS)

[Rutger Hofman]

Andrew Lunn wrote:
> On Sat, Nov 15, 2008 at 04:56:56PM +0100, Rutger Hofman wrote:
>> Good afternoon list,
>>
>> I am making good progress with YAFFS on top of the eCos NAND Flash  
>> library; I can mkdir/rmdir, opendir/readdir, rename, open/creat/unlink,  
>> read/write files, and walk the directory tree on my NAND flash chip.
>>
>> Now, one thing I am unhappy about is file/directory permissions. YAFFS  
>> has permissions (user/group/other a la POSIX), but eCos has no chmod()  
>> call. In old exchanges on this list I saw this crop up on FAT, but FAT's  
>> attributes are different from (POSIX) file permissions. Some guru back  
>> then advised an implementation of chmod() that calls cyg_fs_setinfo()  
>> with a FS_INFO_CHMOD tag. But this route was not taken: I see no chmod()  
>> anywhere.
>>
>> Would it be a good idea that I add chmod() to file.cxx/fileio.h that  
>> does take the above route, and implement it by having it call  
>> cyg_fs_setinfo() with a tag FS_INFO_CHMOD? My guess is that this  
>> shouldn't break the other filesystems, they would return an error code  
>> on an unknown tag FS_INFO_CHMOD.
> 
> The problem with permissions is that they require a concept of a user
> identity. eCos does not have this. There is no uid to know if the user
> owns the file. There is no group of users to know if the group
> permissions are valid. So how do you decide which of the ugo bits to
> look at?
> 
> Without a concept of ugo, how is YAFFS even using the ugo permission?
> I feel that in eCos chmod() is pointless...

Yes, certainly it's correct that ugo does not make very much sense in eCos.

But:

- my aim is that YAFFS filesystems can also be approached from u-boot, 
uCLinux, Linux, ..., even if they are created by eCos; Linux and friends 
do support ugo;
- even if there is no ugo, a permissions notion might make sense. So, if 
the mask is 000 there is no permission at all. 777 would allow everything;
- eCos has open()/creat() with permissions. It has stat() with 
permissions. It has access() with permissions. Ruling out chmod() 
because permissions don't make sense for chmod() seems not completely 
consistent;
- of course I can make an fs-private flag FS_YAFFS_INFO_CHMOD and call 
cyg_fs_setinfo() from the application. I do not feel attracted to that 
in comparison with having chmod(), because it makes the fs type manifest 
to the application.

Rutger

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss