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
