* Extended attributes @ 2014-01-13 13:53 Pavel Fedin 2014-01-13 14:10 ` Corinna Vinschen 0 siblings, 1 reply; 8+ messages in thread From: Pavel Fedin @ 2014-01-13 13:53 UTC (permalink / raw) To: cygwin Hello! Is there any support for xattrs ? I sometimes work with SquashFS images which make use of them (like security.capability) and i'd like to be able to store them along files. If not implemented, can this be somehow fulfilled ? For example, we could store them in a dedicated NTFS stream. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extended attributes 2014-01-13 13:53 Extended attributes Pavel Fedin @ 2014-01-13 14:10 ` Corinna Vinschen 2014-01-15 6:27 ` Pavel Fedin 0 siblings, 1 reply; 8+ messages in thread From: Corinna Vinschen @ 2014-01-13 14:10 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 717 bytes --] On Jan 13 17:53, Pavel Fedin wrote: > Hello! > > Is there any support for xattrs ? I sometimes work with SquashFS images > which make use of them (like security.capability) and i'd like to be able to > store them along files. > If not implemented, can this be somehow fulfilled ? For example, we could > store them in a dedicated NTFS stream. "user." xattrs are supported, but no others. This is partially to have smooth support of xattrs when using Samba shares. See the attr package and the getxattr, etc. calls in Cygwin's ntea.cc. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Extended attributes 2014-01-13 14:10 ` Corinna Vinschen @ 2014-01-15 6:27 ` Pavel Fedin 2014-01-15 9:15 ` Corinna Vinschen 0 siblings, 1 reply; 8+ messages in thread From: Pavel Fedin @ 2014-01-15 6:27 UTC (permalink / raw) To: cygwin Hello! > "user." xattrs are supported, but no others. This is partially to have > smooth support of xattrs when using Samba shares. See the attr > package and the getxattr, etc. calls in Cygwin's ntea.cc. Yes, i have checked that. What do you think about adding other possible namespaces (system, security, and... don't remember the 3rd one) ? So that when manipulating UNIX archives etc these attributes could be kept along with files ? At least we have one use case now. P.S. Sorry if the message duplicates. I have tried to send it from home, but for some reason it got swallowed. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extended attributes 2014-01-15 6:27 ` Pavel Fedin @ 2014-01-15 9:15 ` Corinna Vinschen 2014-01-16 6:08 ` Pavel Fedin 0 siblings, 1 reply; 8+ messages in thread From: Corinna Vinschen @ 2014-01-15 9:15 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1102 bytes --] On Jan 15 10:27, Pavel Fedin wrote: > Hello! > > > "user." xattrs are supported, but no others. This is partially to have > > smooth support of xattrs when using Samba shares. See the attr > > package and the getxattr, etc. calls in Cygwin's ntea.cc. > > Yes, i have checked that. > What do you think about adding other possible namespaces (system, > security, and... don't remember the 3rd one) ? So that when > manipulating UNIX archives etc these attributes could be kept along > with files ? At least we have one use case now. That doesn't make sense. Extended attributes as implemented by Windows are user attributes, not system attributes. The non-user attributes on Linux have a very special meaning to the kernel and/or are restricted to privileged users only. Their functionality is already provided by other OS functions (as for system.posix_acl_access) or not at all (as for security.selinux). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Extended attributes 2014-01-15 9:15 ` Corinna Vinschen @ 2014-01-16 6:08 ` Pavel Fedin 2014-01-16 9:16 ` Corinna Vinschen 0 siblings, 1 reply; 8+ messages in thread From: Pavel Fedin @ 2014-01-16 6:08 UTC (permalink / raw) To: cygwin Hello! > > What do you think about adding other possible namespaces (system, > > security, and... don't remember the 3rd one) ? So that when > > manipulating UNIX archives etc these attributes could be kept along > > with files ? At least we have one use case now. > > That doesn't make sense. Extended attributes as implemented by Windows > are user attributes, not system attributes. The non-user attributes on > Linux have a very special meaning to the kernel and/or are restricted > to privileged users only. Their functionality is already provided by > other OS functions (as for system.posix_acl_access) or not at all (as > for security.selinux). I know they have special meaning. At the other hand, if we allow them, we will allow to store them on a filesystem. Wouldn't it be nice ? This is useful at least for SquashFS image preparation. I guess for similar reasons we have support e. g. for device nodes (/dev) with their major/minor numbers. They are also ignored by Cygwin, and just stored on the filesystem (or do i miss something ?). Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extended attributes 2014-01-16 6:08 ` Pavel Fedin @ 2014-01-16 9:16 ` Corinna Vinschen 2014-01-16 18:52 ` Christopher Faylor 2014-01-20 5:22 ` Pavel Fedin 0 siblings, 2 replies; 8+ messages in thread From: Corinna Vinschen @ 2014-01-16 9:16 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2617 bytes --] On Jan 16 10:08, Pavel Fedin wrote: > Hello! > > > > What do you think about adding other possible namespaces (system, > > > security, and... don't remember the 3rd one) ? So that when > > > manipulating UNIX archives etc these attributes could be kept along > > > with files ? At least we have one use case now. > > > > That doesn't make sense. Extended attributes as implemented by Windows > > are user attributes, not system attributes. The non-user attributes on > > Linux have a very special meaning to the kernel and/or are restricted > > to privileged users only. Their functionality is already provided by > > other OS functions (as for system.posix_acl_access) or not at all (as > > for security.selinux). > > I know they have special meaning. At the other hand, if we allow > them, we will allow to store them on a filesystem. Wouldn't it be > nice ? This is useful at least for SquashFS image preparation. > I guess for similar reasons we have support e. g. for device nodes > (/dev) with their major/minor numbers. They are also ignored by > Cygwin, and just stored on the filesystem (or do i miss something ?). Yes, the history. The device nodes were a start to implement actual loadable device handler code (application level, not actual device drivers), but for some reason it was never fully implemented. I'm really not inclined to add this. As it is, the NTFS xattr are always treated as user attributes. An NTFS attr "foo.bar" is returned as "user.foo.bar" and when writing, a "user.foo.bar" is written as "foo.bar". Adding other attribute types requires to add some special casing and parsing code to differ user attributes from other attributes without breaking backward compatibility. Also, it will never work correctly on a Samba share, because Samba will always treat the incoming attribute as above. So, if you write an attribute "trusted.md5sum" on a samba share, it will actually be converted to "user.trusted.md5sum" by Samba. Another point is stuff like system.posix_acl_access. It's the underlying implementation of POSIX ACLs on Linux, so an application with sufficient access rights could read and write the content directly, rather than using the system calls. But the surprise from the application point of view is, the "system.posix_acl_access" xattrs will have no effect in terms of permissions. Having said that, http://cygwin.com/acronyms/#PTC. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Extended attributes 2014-01-16 9:16 ` Corinna Vinschen @ 2014-01-16 18:52 ` Christopher Faylor 2014-01-20 5:22 ` Pavel Fedin 1 sibling, 0 replies; 8+ messages in thread From: Christopher Faylor @ 2014-01-16 18:52 UTC (permalink / raw) To: cygwin On Thu, Jan 16, 2014 at 10:16:00AM +0100, Corinna Vinschen wrote: >On Jan 16 10:08, Pavel Fedin wrote: >> Hello! >> >> > > What do you think about adding other possible namespaces (system, >> > > security, and... don't remember the 3rd one) ? So that when >> > > manipulating UNIX archives etc these attributes could be kept along >> > > with files ? At least we have one use case now. >> > >> > That doesn't make sense. Extended attributes as implemented by Windows >> > are user attributes, not system attributes. The non-user attributes on >> > Linux have a very special meaning to the kernel and/or are restricted >> > to privileged users only. Their functionality is already provided by >> > other OS functions (as for system.posix_acl_access) or not at all (as >> > for security.selinux). >> >> I know they have special meaning. At the other hand, if we allow >> them, we will allow to store them on a filesystem. Wouldn't it be >> nice ? This is useful at least for SquashFS image preparation. >> I guess for similar reasons we have support e. g. for device nodes >> (/dev) with their major/minor numbers. They are also ignored by >> Cygwin, and just stored on the filesystem (or do i miss something ?). > >Yes, the history. The device nodes were a start to implement actual >loadable device handler code (application level, not actual device >drivers), but for some reason it was never fully implemented. If you're talking about the ability to create a device file anywhere that was something that I did. It wasn't to implement loadable device handlers but just so that we could eventually have a real /dev populated with device files. However, we have since gone the route of creating a pseudo-filesystem /dev so that's no longer necessary. I also did this to allow the creation of fifos anywhere so that's still a valid use case. And, actually, creating a device node anywhere is certainly something that you need to be able to do if you want to claim Linux-like functionality. Device nodes are not (or are not supposed to be) "ignored by Cygwin". cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Extended attributes 2014-01-16 9:16 ` Corinna Vinschen 2014-01-16 18:52 ` Christopher Faylor @ 2014-01-20 5:22 ` Pavel Fedin 1 sibling, 0 replies; 8+ messages in thread From: Pavel Fedin @ 2014-01-20 5:22 UTC (permalink / raw) To: cygwin Hello! > I'm really not inclined to add this. As it is, the NTFS xattr are > always treated as user attributes. An NTFS attr "foo.bar" is returned > as "user.foo.bar" and when writing, a "user.foo.bar" is written as > "foo.bar". Adding other attribute types requires to add some special > casing and parsing code to differ user attributes from other attributes > without breaking backward compatibility. > > Also, it will never work correctly on a Samba share, because Samba will > always treat the incoming attribute as above. So, if you write an > attribute "trusted.md5sum" on a samba share, it will actually be > converted to "user.trusted.md5sum" by Samba. Sorry for late reply, too busy at work now... The same about NFS-related packages - no time ATM to make them... :( You know, i got your point, and perhaps this can be rethought. Perhaps this can be done on SquashFS side. For example, we could tell it to store 'security.foo' attribute as 'user.squashfs.security.foo'. This could be also useful on Linux, because in this case you don't have to be root any more to be able to prepare a rootfs for your embedded device. I think i'll consider that after i finish up with NFS. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-01-20 5:22 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-01-13 13:53 Extended attributes Pavel Fedin 2014-01-13 14:10 ` Corinna Vinschen 2014-01-15 6:27 ` Pavel Fedin 2014-01-15 9:15 ` Corinna Vinschen 2014-01-16 6:08 ` Pavel Fedin 2014-01-16 9:16 ` Corinna Vinschen 2014-01-16 18:52 ` Christopher Faylor 2014-01-20 5:22 ` Pavel Fedin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).