Re: [Bug-tar] adding ACLs when there are none
Hello Linda, On Tuesday, March 04, 2014 15:38:22 Linda A. Walsh wrote: Pavel Raiskup wrote: When --acls option is on (regardless of tarball contents or tarball format), we should explicitly set OR delete default ACLs for extracted directories. Prior to this update, we always created arbitrary default ACLs based standard file permissions. Why would tar create any acls if there are none in the source tar? I was not clear in the sentence probably, please read that like: Set (if these default ACLs are also in archive) OR delete them (because these may already be inherited from parent directory default ACLs). -- When you pass --acls, you want to have extracted files exactly as stored in the archive (from the ACLs perspective). If I read correctly, in ACLs compatbile world — no-ACLs means that you know that you don't want ACLs to be used. I saw someone else have a similar complaint about acls being created when the tar didn't have acls but the --acls option was used. Isn't that exactly the reason for 7fe7adcbb9 commit? Prior to that commit, *default* ACLs were created. From `man acl`: OBJECT CREATION AND DEFAULT ACLs The access ACL of a file object is initialized when the object is created with any of the creat(), mkdir(), mknod(), mkfifo(), or open() functions. If a default ACL is associated with a directory, the mode parameter to the functions creating file objects and the default ACL of the directory are used to determine the ACL of the new object: I wouldn't want a non-acl containing tarball to overwrite or change default acls in a directory that already exists. If I said --acl=reset or similar, that might be a desirable feature. These are IMO candidates for omitting --acls option, no? Or could you give an example? What *exactly* do you expect the --acls should behave by default? Combine existing acls in parent directory (default acls) with the stored in archive? Thanks, Pavel
Re: [Bug-tar] adding ACLs when there are none
Pavel Raiskup wrote: These are IMO candidates for omitting --acls option, no? Or could you give an example? What *exactly* do you expect the --acls should behave by default? Combine existing acls in parent directory (default acls) with the stored in archive? Leaving default acls in the dir -- case in in point... If the SetGid bit is set on a directory on linux, it is usually propagated to lower lower level dirs to permit a particular type of access to be propagated to lower level files and dirs. If a default acl is set on a dir I see it used in the same way.
Re: [Bug-tar] adding ACLs when there are none
Pavel Raiskup wrote: Or could you give an example? What *exactly* do you expect the --acls should behave by default? Combine existing acls in parent directory (default acls) with the stored in archive? Thanks, Pavel - Sorry, didn't finish that thought...If there are default acls set in the tar, they would replace such default acls that are present, but undefined ACLs in the tar wouldn't overwrite set acl's that propagate from the parent.
Re: [Bug-tar] adding ACLs when there are none
On Wednesday, March 05, 2014 05:06:06 Linda A. Walsh wrote: Pavel Raiskup wrote: Or could you give an example? What *exactly* do you expect the --acls should behave by default? Combine existing acls in parent directory (default acls) with the stored in archive? Thanks, Pavel - If the SetGid bit is set on a directory on linux, it is usually propagated to lower lower level dirs to permit a particular type of access to be propagated to lower level files and dirs. The _default_ seems to be matter of taste. Looking at how the SetGid works in GNU tar, the bit is inherited from parent by default (no additional option passed). But when you specify '-p' option, then the bit is not inherited as you want (the permissions stored in archive have a priority). I would rather take --acls similarly to -p in this regard. If a default acl is set on a dir I see it used in the same way. Sorry, didn't finish that thought...If there are default acls set in the tar, they would replace such default acls that are present, but undefined ACLs in the tar wouldn't overwrite set acl's that propagate from the parent. And what if you want to combine default ACLs somehow? Also what if you want the inherited (not in archive-stored) ACLs to affect also all extracted files? I agree that you may want to specify exact behavior. The --acls could take optional arguments like --acls=inherit-defaults (your scenario). Possibly --acls=combine (in future) to merge as much as possible (little bit more work here would be needed). Thoughts? Pavel
Re: [Bug-tar] adding ACLs when there are none
Pavel Raiskup prais...@redhat.com wrote: On Wednesday, March 05, 2014 05:06:06 Linda A. Walsh wrote: Pavel Raiskup wrote: Or could you give an example? What *exactly* do you expect the --acls should behave by default? Combine existing acls in parent directory (default acls) with the stored in archive? Thanks, Pavel - If the SetGid bit is set on a directory on linux, it is usually propagated to lower lower level dirs to permit a particular type of access to be propagated to lower level files and dirs. The _default_ seems to be matter of taste. Looking at how the SetGid works in GNU tar, the bit is inherited from parent by default (no additional option passed). But when you specify '-p' option, then the bit is not inherited as you want (the permissions stored in archive have a priority). I would rather take --acls similarly to -p in this regard. This does nit seem to be correct. The BSD sgroup bit on directories only propagates to directories and not to files. The default acls propagate to files also. Note that the bevior in star has been defined in 2001 after talking to various people. gtar should behave similar. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [Bug-tar] adding ACLs when there are none
Pavel Raiskup wrote: When --acls option is on (regardless of tarball contents or tarball format), we should explicitly set OR delete default ACLs for extracted directories. Prior to this update, we always created arbitrary default ACLs based standard file permissions. Why would tar create any acls if there are none in the source tar? I saw someone else have a similar complaint about acls being created when the tar didn't have acls but the --acls option was used. I wouldn't want a non-acl containing tarball to overwrite or change default acls in a directory that already exists. I wouldn't want acl=undef to overwrite a set value. I just was working on a parameter passing routine -- and had to think -- did I really want undef (in perl) to overwrite a defined value? If I said --acl=reset or similar, that might be a desirable feature. But I use default acls and certainly wouldn't want them cleared as a normal action when there are no replacing acls specified.
