This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: chmod (crops up on YAFFS)
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Rutger Hofman <rutger at cs dot vu dot nl>
- Cc: "ecos-discuss at ecos dot sourceware dot org" <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 18 Nov 2008 15:48:12 +0000
- Subject: Re: [ECOS] chmod (crops up on YAFFS)
- Openpgp: id=A5FB74E6
- References: <491EF148.5040005@cs.vu.nl> <20081115160903.GB472@lunn.ch> <4922C54A.6030901@cs.vu.nl>
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