Re: [ECOS] chmod (crops up on YAFFS)

[Jonathan Larmour <jifl at eCosCentric dot com>]

Rutger Hofman wrote:
> Andrew Lunn wrote:
>> On Sat, Nov 15, 2008 at 04:56:56PM +0100, Rutger Hofman wrote:
>>>
>>> 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.

I think Andrew's point was just checking your expectations: it should be ok
to write the uid/gid and permissions info given it can be used by Linux
subsequently. But we shouldn't be checking anything. It should be as if
eCos is running as root. -EACCES is not an error code we're likely to see
(although in due course once we have network filesystems we might).

I think your original proposal sounds fine - implement chmod() with
cyg_fs_setinfo() with a tag FS_INFO_CHMOD. You will probably similarly want
chown().

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

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