Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Extended attributesExtended attributesPosted Apr 14, 2005 21:11 UTC (Thu) by proski (subscriber, #104)Parent article: FUSE hits a snag Wouldn't it be reasonable to present the native permissions as extended attributes rather than as UNIX permissions? For example, if a file over ssh connection belongs to a user that doesn't exist locally, how do you map it to a local user ID? But an extended attribute "owner" could have a string value for the actual owner of the file. If the permissions on a file don't reflect what file operations are actually allowed, what's the point in presenting them as permissions? An ACL editor would be more suitable for viewing and changing those permissions than chmod and chown.
(Log in to post comments)
Extended attributes Posted Apr 16, 2005 0:40 UTC (Sat) by giraffedata (subscriber, #1954) [Link] If the permissions on a file don't reflect what file operations are actually allowed, what's the point in presenting them as permissions? The point is that some people want to use the standard tools, not an arcane ACL editor made just for that job. FUSE is all about making something look like a traditional filesystem so your traditional tools and skills work with it. If not for that, you might as well use a tar file editor instead of mounting your tar file as a filesystem. The arguments against acknowledge that value, but just point out that the downside -- the cases where the model breaks and the fact that the permissions aren't really permissions shows -- outweighs it.
Extended attributes Posted Apr 21, 2005 7:49 UTC (Thu) by xoddam (subscriber, #2322) [Link] It seems to me that the special semantics are no more or less thana user could trick his/her processes to see with other, purely userspace tools using LD_PRELOAD, such as fakeroot. The point of FUSE is merely to facilitate the task. In other words, it's the users' business what semantics they present to themselves, and not a kernel hacker's problem. Looking at the application with full generality, you want to have the flexibility to map users and permissions about in any way you wish, just as you might remap uids and usernames over NFS or SMB, or 'squish' root privileges to nothing. And in this case, the power do do that remapping belongs to the person running 'mount'.
User-controlled file permission semantics with FUSE Posted Apr 21, 2005 15:39 UTC (Thu) by giraffedata (subscriber, #1954) [Link] It seems to me that the special semantics are no more or less than a user could trick his/her processes to see with other, purely userspace tools using LD_PRELOAD I think the point is just that users presumably would like in some cases both to have access to files with FUSE and have normal semantics. FUSE should provide users that capability if possible. Also, in the proposal, mounting a filesystem affects other processes -- all those owned by the same user see the mounted files with unconventional permission semantics.
|
|||||||||||