Re: [Bug-tar] ACL support in git version of GNU tar
I have rebased my patches to GNU tar 1.28 - clone the git repository git://gitorious.org/tar-fcaps/tar-fcaps.git to access them and look in the branch pu (ACL patches) and pu2 (Capabilities patch). If you wonder: I am using the version in branch "msteinborn-1.28". Greetings from Germany Markus Steinborn Markus Steinborn wrote: I've still no decision about the following - let me add one note to it: Patch 2 of the series contained a bug - take the attached file as a replacement. Markus Steinborn wrote: What about the following patches? Markus Steinborn wrote Hi, I'd like to remember of the following bug report and to announce that I have finished patches for all these issues. I have submitted my patches to redhat (as they currently apply clean on a redhat patched tar 1.27.1). See https://bugzilla.redhat.com/show_bug.cgi?id=1052876 for them. If you are ready to accept that patches (and only then, currently I have quite limited time) I would rebase the patches to tar master. I also want to remind of http://lists.gnu.org/archive/html/bug-tar/2013-04/msg00024.html: where "Paul Eggert" writes "That sort of thing all sounds reasonable, I guess. I'd like Sergey's opinion though.". What is your opinion to this, Sergey? Greetings from Germany Markus Steinborn GNU gv maintainer Markus Steinborn schrieb: Hi everybody, Today I noticed that GNU tar (git master) now supports XATTRs, ACLs and SELINUX-Attributes. I am really pleased to read this in "git log". Congratualtions for this improvement. The improvements do not break star und redhat tar compatibility. Having used Redhats patch for many years now (and an improved version which I made), I am able to enumerate a few points that IMHO need improvement: (1) tar archive creation with "--numeric-owner" option: In this case, users are expectiing that the archive does not contain any symbolic owner name, so it can be extracted to an emoty hard disc on a system bootet e. g. by a rescue cd from Redhat. Current sitation is that ACLs still include the symbolic owner and not the numeric owner. This is quite trivial to fix: Replace all ocurences of "val = acl_to_text(acl, &len);" by "val = acl_to_any_text(acl, 0, ',', ( numeric_owner_option?TEXT_NUMERIC_IDS:0));" and followed by "len=strlen(val);" after the "if (!val)" error-handling. Effect: Numeric owner is stored. I'd like to note that this improvement is essential to me. (2a) tar archive creation without "--numeric-owner" option: In GNU tar 1.26, for every file the owner is stored both, symbolic and numeric. I would expect that ACLs are stored in both ways, too. star shows us how to do that: star stores the numeric owner in a forth field of an acl: (e.g. "u:msteinbo:rwx:500"). (2b) tar extract should use the 4th field (discussed in point 2) in presence of "-numeric-owner". This together with point (2) enabled users to restore an backup created without numeric owner option on a clean hard disc without passwd entries for the users (let's assume that /etc/passwd is contained in the archive so the operation makes sense). I'd like to mention that this point would increase star compatibility a lot. Optional (3): Do not store ACLs iff ACL contains just the normal user, group and other permissions, i. .e. the ACL is an compatibility ACL. What is your opinion on these points? Greetings from Germany Markus Steinborn GNU gv maintainer PS: "iff" is the usual abbreviation for "if and only if" and not a typo.
Re: [Bug-tar] ACL support in git version of GNU tar
I've still no decision about the following - let me add one note to it:
Patch 2 of the series contained a bug - take the attached file as a
replacement.
Markus Steinborn wrote:
What about the following patches?
Markus Steinborn wrote
Hi,
I'd like to remember of the following bug report and to announce that
I have finished patches for all these issues.
I have submitted my patches to redhat (as they currently apply clean
on a redhat patched tar 1.27.1). See
https://bugzilla.redhat.com/show_bug.cgi?id=1052876 for them.
If you are ready to accept that patches (and only then, currently I
have quite limited time) I would rebase the patches to tar master.
I also want to remind of
http://lists.gnu.org/archive/html/bug-tar/2013-04/msg00024.html:
where "Paul Eggert" writes "That sort of thing all sounds reasonable,
I guess. I'd like Sergey's opinion though.". What is your opinion to
this, Sergey?
Greetings from Germany
Markus Steinborn
GNU gv maintainer
Markus Steinborn schrieb:
Hi everybody,
Today I noticed that GNU tar (git master) now supports XATTRs, ACLs
and SELINUX-Attributes. I am really pleased to read this in "git
log". Congratualtions for this improvement. The improvements do not
break star und redhat tar compatibility.
Having used Redhats patch for many years now (and an improved
version which I made), I am able to enumerate a few points that IMHO
need improvement:
(1) tar archive creation with "--numeric-owner" option:
In this case, users are expectiing that the archive does not contain
any symbolic owner name, so it can be extracted to an emoty hard
disc on a system bootet e. g. by a rescue cd from Redhat. Current
sitation is that ACLs still include the symbolic owner and not the
numeric owner.
This is quite trivial to fix:
Replace all ocurences of "val = acl_to_text(acl, &len);" by "val =
acl_to_any_text(acl, 0, ',', (
numeric_owner_option?TEXT_NUMERIC_IDS:0));" and followed by
"len=strlen(val);" after the "if (!val)" error-handling.
Effect: Numeric owner is stored.
I'd like to note that this improvement is essential to me.
(2a) tar archive creation without "--numeric-owner" option:
In GNU tar 1.26, for every file the owner is stored both, symbolic
and numeric. I would expect that ACLs are stored in both ways, too.
star shows us how to do that:
star stores the numeric owner in a forth field of an acl: (e.g.
"u:msteinbo:rwx:500").
(2b) tar extract should use the 4th field (discussed in point 2) in
presence of "-numeric-owner".
This together with point (2) enabled users to restore an backup
created without numeric owner option on a clean hard disc without
passwd entries for the users (let's assume that /etc/passwd is
contained in the archive so the operation makes sense).
I'd like to mention that this point would increase star
compatibility a lot.
Optional (3): Do not store ACLs iff ACL contains just the normal
user, group and other permissions, i. .e. the ACL is an
compatibility ACL.
What is your opinion on these points?
Greetings from Germany
Markus Steinborn
GNU gv maintainer
PS: "iff" is the usual abbreviation for "if and only if" and not a
typo.
>From 28e41ac29753a2b00fb3a6602206ba81f0d0f879 Mon Sep 17 00:00:00 2001
From: Markus Steinborn
Date: Sun, 6 Oct 2013 11:50:07 +0200
Subject: [PATCH 2/5] tar archive creation without "--numeric-owner" option
In GNU tar 1.26, for every file the owner is stored both, symbolic and
numeric. I would expect that ACLs are stored in both ways, too. star shows
us how to do that:
star stores the numeric owner in a forth field of an acl:
(e.g. "u:msteinbo:rwx:500").
ACLs: tar archive creation with "--numeric-owner" option
In this case, users are expectiing that the archive does not contain any
symbolic owner name, so it can be extracted to an emoty hard disc on a
---
src/xattrs.c | 202 ++-
1 file changed, 200 insertions(+), 2 deletions(-)
diff --git a/src/xattrs.c b/src/xattrs.c
index c06878e..945c6c0 100644
--- a/src/xattrs.c
+++ b/src/xattrs.c
@@ -53,6 +53,7 @@ static struct
#ifdef HAVE_POSIX_ACLS
# include "acl.h"
# include
+# include
#endif
#ifdef HAVE_POSIX_ACLS
@@ -497,12 +498,179 @@ xattrs__acls_set (struct tar_stat_info const *st,
acl_free (acl);
}
+bool name2uid(char *name, unsigned long *uidp)
+{
+ struct passwd *pw;
+
+ if (!*name)
+ return false;
+
+ if ((pw = getpwnam(name)) != NULL) {
+ *uidp = pw->pw_uid;
+ return true;
+ } else {
+ *uidp = 0;
+ return false;
+ }
+}
+
+bool name2gid(char* name, unsigned long *gidp)
+{
+ struct group *gr;
+
+ if (!*name)
+ return false;
+
+ if ((gr = getgrnam(name)) != NULL) {
+ *gidp = gr->gr_gid;
+ return true;
+ } else {
+ *gidp = 0;
+ return false;
+ }
+}
+
+static bool acl_add_ids(char* acltext, char** retInfotext)
+{
+ int ret, dstlen;
+ char *tmp, *tmp2, *src, *dst;
+ tmp = malloc( 1+strlen(acltext) );
+ acl_check
Re: [Bug-tar] ACL support in git version of GNU tar
Sergey Poznyakoff schrieb: Yes, they are next in my queue. That are great news. IMHO tweaking the xattr-related options would be good. The portablity problems even between different linux kernel versions of File capatibilies lead me to the point that I'd like to archive only user.* xattrs, and security.* xattrs iff a specific xattr handler is available (e. g. for ACLs we have one, and for Capabilities there is my patch available for handling them). So adjusting the options would be good, perhaps --aclsWill archive .what it currently does --acls=user Only user.* --acls=wellknown Only user..*, security.*. --acls=all Will archive all acls, should imply acls-include. Those being handled separately should not being archived as xattr (extracting them might overwrite a correctly restored entry by a wrong one, e. g. UIDs changed). Gven that is point has not been discussed in public, my patch does not propose a ready to use options handling. Greetings Markus Steinborn
Re: [Bug-tar] ACL support in git version of GNU tar
Hi Markus, > What about the following patches? Yes, they are next in my queue. Regards, Sergey
Re: [Bug-tar] ACL support in git version of GNU tar
What about the following patches? Markus Steinborn wrote Hi, I'd like to remember of the following bug report and to announce that I have finished patches for all these issues. I have submitted my patches to redhat (as they currently apply clean on a redhat patched tar 1.27.1). See https://bugzilla.redhat.com/show_bug.cgi?id=1052876 for them. If you are ready to accept that patches (and only then, currently I have quite limited time) I would rebase the patches to tar master. I also want to remind of http://lists.gnu.org/archive/html/bug-tar/2013-04/msg00024.html: where "Paul Eggert" writes "That sort of thing all sounds reasonable, I guess. I'd like Sergey's opinion though.". What is your opinion to this, Sergey? Greetings from Germany Markus Steinborn GNU gv maintainer Markus Steinborn schrieb: Hi everybody, Today I noticed that GNU tar (git master) now supports XATTRs, ACLs and SELINUX-Attributes. I am really pleased to read this in "git log". Congratualtions for this improvement. The improvements do not break star und redhat tar compatibility. Having used Redhats patch for many years now (and an improved version which I made), I am able to enumerate a few points that IMHO need improvement: (1) tar archive creation with "--numeric-owner" option: In this case, users are expectiing that the archive does not contain any symbolic owner name, so it can be extracted to an emoty hard disc on a system bootet e. g. by a rescue cd from Redhat. Current sitation is that ACLs still include the symbolic owner and not the numeric owner. This is quite trivial to fix: Replace all ocurences of "val = acl_to_text(acl, &len);" by "val = acl_to_any_text(acl, 0, ',', ( numeric_owner_option?TEXT_NUMERIC_IDS:0));" and followed by "len=strlen(val);" after the "if (!val)" error-handling. Effect: Numeric owner is stored. I'd like to note that this improvement is essential to me. (2a) tar archive creation without "--numeric-owner" option: In GNU tar 1.26, for every file the owner is stored both, symbolic and numeric. I would expect that ACLs are stored in both ways, too. star shows us how to do that: star stores the numeric owner in a forth field of an acl: (e.g. "u:msteinbo:rwx:500"). (2b) tar extract should use the 4th field (discussed in point 2) in presence of "-numeric-owner". This together with point (2) enabled users to restore an backup created without numeric owner option on a clean hard disc without passwd entries for the users (let's assume that /etc/passwd is contained in the archive so the operation makes sense). I'd like to mention that this point would increase star compatibility a lot. Optional (3): Do not store ACLs iff ACL contains just the normal user, group and other permissions, i. .e. the ACL is an compatibility ACL. What is your opinion on these points? Greetings from Germany Markus Steinborn GNU gv maintainer PS: "iff" is the usual abbreviation for "if and only if" and not a typo.
Re: [Bug-tar] ACL support in git version of GNU tar
Hi Pavel, Pavel Raiskup wrote: Still, even as a Fedora/RHEL (co)maintainer I would prefer making the patches pass against GNU git master. It makes things more easy for GNU tar upstream and it is not problem for me to backport such patches to Fedora. I see. This has come from the following fact: As of my limited time, I've begun with the version I needed. And I am using your src rpm from koji as an excellent base for my centos machines... and have plans to setup a fedora machine for the tasks where a recent autoconf/automake is needed. And yes, it cannot be wrong to post the patches one has ready... Rebasing (if needed) can be done later. If I look at this list in the recent past, there may be more than one rebase needed till iinclusion... where we return to my time argument Current patches will allow anyone to test them - it should not be a problem to include relevant redhat patches for this test (this might be another idea: Post the relevant xattr patches from redhat instead of patchiing - I'd expect that then everything applies perfect). But not that this plays important role also for Fedora inclusion — we should really meet the upstream quality of backported patches. So I don't think that the patch review should be done on Fedora side. I can help with reviewing if that will be needed.. But yes, we need to know upstream POV. You are welcome... Fot the ease of reading, I seperated each piece of changes from my original list into seperate patch, where a patch might require previous patches or not. Note that I did not announce the Capability patch upstream - so we should doscuss that in another thread here or in redhats bugzilla. For upstream, it will probably require some changes (it currently requires a configure argument to be enabled - not really a problem for binary linux distributions, but for upstreamm, it might be a problem). Greetings Markus Steinborn
Re: [Bug-tar] ACL support in git version of GNU tar
> I'd like to remember of the following bug report and to announce that I > have finished patches for all these issues. Marcus, thanks for looking at this problem. I think fixes for ACLs/capabilities are really important, though I have not looked at your code yet. > I have submitted my patches to redhat (as they currently apply clean on > a redhat patched tar 1.27.1). See > https://bugzilla.redhat.com/show_bug.cgi?id=1052876 for them. > > If you are ready to accept that patches (and only then, currently I have > quite limited time) I would rebase the patches to tar master. Still, even as a Fedora/RHEL (co)maintainer I would prefer making the patches pass against GNU git master. It makes things more easy for GNU tar upstream and it is not problem for me to backport such patches to Fedora. > I also want to remind of > http://lists.gnu.org/archive/html/bug-tar/2013-04/msg00024.html: where > "Paul Eggert" writes "That sort of thing all sounds reasonable, I guess. > I'd like Sergey's opinion though.". What is your opinion to this, Sergey? But not that this plays important role also for Fedora inclusion — we should really meet the upstream quality of backported patches. So I don't think that the patch review should be done on Fedora side. I can help with reviewing if that will be needed.. But yes, we need to know upstream POV. Pavel
Re: [Bug-tar] ACL support in git version of GNU tar
Hi, I'd like to remember of the following bug report and to announce that I have finished patches for all these issues. I have submitted my patches to redhat (as they currently apply clean on a redhat patched tar 1.27.1). See https://bugzilla.redhat.com/show_bug.cgi?id=1052876 for them. If you are ready to accept that patches (and only then, currently I have quite limited time) I would rebase the patches to tar master. I also want to remind of http://lists.gnu.org/archive/html/bug-tar/2013-04/msg00024.html: where "Paul Eggert" writes "That sort of thing all sounds reasonable, I guess. I'd like Sergey's opinion though.". What is your opinion to this, Sergey? Greetings from Germany Markus Steinborn GNU gv maintainer Markus Steinborn schrieb: Hi everybody, Today I noticed that GNU tar (git master) now supports XATTRs, ACLs and SELINUX-Attributes. I am really pleased to read this in "git log". Congratualtions for this improvement. The improvements do not break star und redhat tar compatibility. Having used Redhats patch for many years now (and an improved version which I made), I am able to enumerate a few points that IMHO need improvement: (1) tar archive creation with "--numeric-owner" option: In this case, users are expectiing that the archive does not contain any symbolic owner name, so it can be extracted to an emoty hard disc on a system bootet e. g. by a rescue cd from Redhat. Current sitation is that ACLs still include the symbolic owner and not the numeric owner. This is quite trivial to fix: Replace all ocurences of "val = acl_to_text(acl, &len);" by "val = acl_to_any_text(acl, 0, ',', ( numeric_owner_option?TEXT_NUMERIC_IDS:0));" and followed by "len=strlen(val);" after the "if (!val)" error-handling. Effect: Numeric owner is stored. I'd like to note that this improvement is essential to me. (2a) tar archive creation without "--numeric-owner" option: In GNU tar 1.26, for every file the owner is stored both, symbolic and numeric. I would expect that ACLs are stored in both ways, too. star shows us how to do that: star stores the numeric owner in a forth field of an acl: (e.g. "u:msteinbo:rwx:500"). (2b) tar extract should use the 4th field (discussed in point 2) in presence of "-numeric-owner". This together with point (2) enabled users to restore an backup created without numeric owner option on a clean hard disc without passwd entries for the users (let's assume that /etc/passwd is contained in the archive so the operation makes sense). I'd like to mention that this point would increase star compatibility a lot. Optional (3): Do not store ACLs iff ACL contains just the normal user, group and other permissions, i. .e. the ACL is an compatibility ACL. What is your opinion on these points? Greetings from Germany Markus Steinborn GNU gv maintainer PS: "iff" is the usual abbreviation for "if and only if" and not a typo.
Re: [Bug-tar] ACL support in git version of GNU tar
Markus Steinborn wrote: > >> star stores the numeric owner in a forth field of an acl: (e.g. > >> "u:msteinbo:rwx:500"). > > Correct, this is an extension to the ACL format that was needed to allow > > ACLs > > to be archivable in a reliable way at all. > > > Well, I have to notice that this is not fixed before release of an ACL > anbeled tar. So every tar archive created with GNU tar 1.27 does not > store ACLs in a reliable way. > > Expect bug reports what that breaks... I would expect to break > everything with numeric owner option. It may also break compatibility with ACL aware tar archives in general - I did not yet check whether this format is readable at all... well let's see: And just a hint: there are no POSIX ACLs. But /tmp/tar-1.27/src/tar: POSIX ACL support is not available does not look convincing on a system that supports the POSX ACL draft that was with drawn in 1997. Sorry, I cannot test as gtar does not seem to support this kind of old ACLs. It seems that there are more problems, the code does not seem to be written in C: CC wordsplit.o "./wordsplit.h", line 37: warning: attribute parameter "__printf__" is undefined "./wordsplit.h", line 37: warning: attribute "format" may not be applied to variable, ignored "./wordsplit.h", line 39: warning: attribute parameter "__printf__" is undefined "./wordsplit.h", line 39: warning: attribute "format" may not be applied to variable, ignored "wordsplit.c", line 64: warning: attribute parameter "__printf__" is undefined This was a forgiving compiler - other compilers would flag a syntax error. what is the planned audience for gtar? 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] ACL support in git version of GNU tar
Joerg Schilling schrieb: Markus Steinborn wrote: (2a) tar archive creation without "--numeric-owner" option: In GNU tar 1.26, for every file the owner is stored both, symbolic and numeric. I would expect that ACLs are stored in both ways, too. star shows us how to do that: star stores the numeric owner in a forth field of an acl: (e.g. "u:msteinbo:rwx:500"). Correct, this is an extension to the ACL format that was needed to allow ACLs to be archivable in a reliable way at all. Well, I have to notice that this is not fixed before release of an ACL anbeled tar. So every tar archive created with GNU tar 1.27 does not store ACLs in a reliable way. Expect bug reports what that breaks... I would expect to break everything with numeric owner option. Greetungs from Germany Markus Steinborn GNU gv maintainer PS: Not good - now I've got to fix tar myself to have a usable tar again... Good luck there are GPL-Codes I can copy extracts from.
Re: [Bug-tar] ACL support in git version of GNU tar
Hi, given that I've read in this mailing list that a release is planed, I'm poiting you to the following: I suggest fixing it before release. Markus Steinborn schrieb: Hi, I'd like to remind the maintainers of GNU tar to the following post to bug-tar: Markus Steinborn schrieb: Hi everybody, Today I noticed that GNU tar (git master) now supports XATTRs, ACLs and SELINUX-Attributes. I am really pleased to read this in "git log". Congratualtions for this improvement. The improvements do not break star und redhat tar compatibility. Having used Redhats patch for many years now (and an improved version which I made), I am able to enumerate a few points that IMHO need improvement: (1) tar archive creation with "--numeric-owner" option: In this case, users are expectiing that the archive does not contain any symbolic owner name, so it can be extracted to an emoty hard disc on a system bootet e. g. by a rescue cd from Redhat. Current sitation is that ACLs still include the symbolic owner and not the numeric owner. This is quite trivial to fix: Replace all ocurences of "val = acl_to_text(acl, &len);" by "val = acl_to_any_text(acl, 0, ',', ( numeric_owner_option?TEXT_NUMERIC_IDS:0));" and followed by "len=strlen(val);" after the "if (!val)" error-handling. Effect: Numeric owner is stored. I'd like to note that this improvement is essential to me. (2a) tar archive creation without "--numeric-owner" option: In GNU tar 1.26, for every file the owner is stored both, symbolic and numeric. I would expect that ACLs are stored in both ways, too. star shows us how to do that: star stores the numeric owner in a forth field of an acl: (e.g. "u:msteinbo:rwx:500"). (2b) tar extract should use the 4th field (discussed in point 2) in presence of "-numeric-owner". This together with point (2) enabled users to restore an backup created without numeric owner option on a clean hard disc without passwd entries for the users (let's assume that /etc/passwd is contained in the archive so the operation makes sense). I'd like to mention that this point would increase star compatibility a lot. Optional (3): Do not store ACLs iff ACL contains just the normal user, group and other permissions, i. .e. the ACL is an compatibility ACL. What is your opinion on these points? Greetings from Germany Markus Steinborn GNU gv maintainer PS: "iff" is the usual abbreviation for "if and only if" and not a typo. Thanks Markus Steinborn
Re: [Bug-tar] ACL support in git version of GNU tar
That sort of thing all sounds reasonable, I guess. I'd like Sergey's opinion though.
Re: [Bug-tar] ACL support in git version of GNU tar
Hi, I'd like to remind the maintainers of GNU tar to the following post to bug-tar: Markus Steinborn schrieb: Hi everybody, Today I noticed that GNU tar (git master) now supports XATTRs, ACLs and SELINUX-Attributes. I am really pleased to read this in "git log". Congratualtions for this improvement. The improvements do not break star und redhat tar compatibility. Having used Redhats patch for many years now (and an improved version which I made), I am able to enumerate a few points that IMHO need improvement: (1) tar archive creation with "--numeric-owner" option: In this case, users are expectiing that the archive does not contain any symbolic owner name, so it can be extracted to an emoty hard disc on a system bootet e. g. by a rescue cd from Redhat. Current sitation is that ACLs still include the symbolic owner and not the numeric owner. This is quite trivial to fix: Replace all ocurences of "val = acl_to_text(acl, &len);" by "val = acl_to_any_text(acl, 0, ',', ( numeric_owner_option?TEXT_NUMERIC_IDS:0));" and followed by "len=strlen(val);" after the "if (!val)" error-handling. Effect: Numeric owner is stored. I'd like to note that this improvement is essential to me. (2a) tar archive creation without "--numeric-owner" option: In GNU tar 1.26, for every file the owner is stored both, symbolic and numeric. I would expect that ACLs are stored in both ways, too. star shows us how to do that: star stores the numeric owner in a forth field of an acl: (e.g. "u:msteinbo:rwx:500"). (2b) tar extract should use the 4th field (discussed in point 2) in presence of "-numeric-owner". This together with point (2) enabled users to restore an backup created without numeric owner option on a clean hard disc without passwd entries for the users (let's assume that /etc/passwd is contained in the archive so the operation makes sense). I'd like to mention that this point would increase star compatibility a lot. Optional (3): Do not store ACLs iff ACL contains just the normal user, group and other permissions, i. .e. the ACL is an compatibility ACL. What is your opinion on these points? Greetings from Germany Markus Steinborn GNU gv maintainer PS: "iff" is the usual abbreviation for "if and only if" and not a typo. Thanks Markus Steinborn
Re: [Bug-tar] ACL support in git version of GNU tar
Markus Steinborn wrote: > Joerg Schilling schrieb: > > With "normal" user credentials in tar, this works, as you may just omit the > > user/group name fields in the tar header. > > > > With ACL fields, you cannot do that as star uses a ACL description that was > > derived from an outdated stanndard proposal. > I've tested this some time ago: > > star can handle ACLs like > > u:500:rwx > > and > > u:500:rwx:500 > > correctly. And all I proposed is to use one of these formats. OK, so it may be an option to let star use 500 instead of "joe" if -numeric was used in create mode. 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] ACL support in git version of GNU tar
Joerg Schilling schrieb: With "normal" user credentials in tar, this works, as you may just omit the user/group name fields in the tar header. With ACL fields, you cannot do that as star uses a ACL description that was derived from an outdated stanndard proposal. I've tested this some time ago: star can handle ACLs like u:500:rwx and u:500:rwx:500 correctly. And all I proposed is to use one of these formats. So if you like to get the behavior you expect with ACLs, you would need to use -numeric during an extract operation. As long as just the name data-base on the system used to extract is missing, star always does what you expect. But on up to date redhat tar's, this option simply does not work. So it does not help in any way. Greetings Markus Steinborn
Re: [Bug-tar] ACL support in git version of GNU tar
Markus Steinborn wrote: > >> (1) tar archive creation with "--numeric-owner" option: > >> > >> In this case, users are expectiing that the archive does not contain any > >> symbolic owner name, so it can be extracted to an emoty hard disc on a > >> system bootet e. g. by a rescue cd from Redhat. Current sitation is that > >> ACLs still include the symbolic owner and not the numeric owner. > [...} > >> I'd like to note that this improvement is essential to me. > > Why? > > > > Star introduced the -numeric option in 1993 to work in create list and > > extract > > mode. The ACL Support introduced in 2001 was created to behave in a similar > > way. > > > > If gtar does the same, the best way would be to use -numeric in extract > > mode. > > > Assume you've created an archive with that option. You want to restore > it to a new hard disc drive. All you have available are redhat rescue > cd's (from today, not from future). Their tar will do it correctly iff > the archives are created with the owner-field being numeric. > > So users could benefit from that proposed change. And it costs so less. With "normal" user credentials in tar, this works, as you may just omit the user/group name fields in the tar header. With ACL fields, you cannot do that as star uses a ACL description that was derived from an outdated stanndard proposal. So if you like to get the behavior you expect with ACLs, you would need to use -numeric during an extract operation. As long as just the name data-base on the system used to extract is missing, star always does what you expect. 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] ACL support in git version of GNU tar
Joerg Schilling schrieb: star stores the numeric owner in a forth field of an acl: (e.g. "u:msteinbo:rwx:500"). Correct, this is an extension to the ACL format that was needed to allow ACLs to be archivable in a reliable way at all. Fine that you agree that GNU gv should support that. (2b) tar extract should use the 4th field (discussed in point 2) in presence of "-numeric-owner". This together with point (2) enabled users to restore an backup created without numeric owner option on a clean hard disc without passwd entries for the users (let's assume that /etc/passwd is contained in the archive so the operation makes sense). I'd like to mention that this point would increase star compatibility a lot. If there is not such behavior, the gtar implementation is of limited usablility. I agree. There are two use cases: 1) File servers that do not import nam services. This is rare toway with NFSv4 2) Deleted user credentials for old employees. This is something that happens frequently. ... and of cause my use case. Conclusion: GNU tar should definitively support it, I think. Greetings from Germany Markus Steinborn
Re: [Bug-tar] ACL support in git version of GNU tar
Joerg Schilling schrieb: Markus Steinborn wrote: Hi everybody, Today I noticed that GNU tar (git master) now supports XATTRs, ACLs and SELINUX-Attributes. I am really pleased to read this in "git log". Congratualtions for this improvement. The improvements do not break star und redhat tar compatibility. Having used Redhats patch for many years now (and an improved version which I made), I am able to enumerate a few points that IMHO need improvement: (1) tar archive creation with "--numeric-owner" option: In this case, users are expectiing that the archive does not contain any symbolic owner name, so it can be extracted to an emoty hard disc on a system bootet e. g. by a rescue cd from Redhat. Current sitation is that ACLs still include the symbolic owner and not the numeric owner. [...} I'd like to note that this improvement is essential to me. Why? Star introduced the -numeric option in 1993 to work in create list and extract mode. The ACL Support introduced in 2001 was created to behave in a similar way. If gtar does the same, the best way would be to use -numeric in extract mode. Assume you've created an archive with that option. You want to restore it to a new hard disc drive. All you have available are redhat rescue cd's (from today, not from future). Their tar will do it correctly iff the archives are created with the owner-field being numeric. So users could benefit from that proposed change. And it costs so less. Greetings Markus Steinborn
Re: [Bug-tar] ACL support in git version of GNU tar
Markus Steinborn wrote: > Hi everybody, > > Today I noticed that GNU tar (git master) now supports XATTRs, ACLs and > SELINUX-Attributes. I am really pleased to read this in "git log". > Congratualtions for this improvement. The improvements do not break star > und redhat tar compatibility. > > Having used Redhats patch for many years now (and an improved version > which I made), I am able to enumerate a few points that IMHO need > improvement: > > > (1) tar archive creation with "--numeric-owner" option: > > In this case, users are expectiing that the archive does not contain any > symbolic owner name, so it can be extracted to an emoty hard disc on a > system bootet e. g. by a rescue cd from Redhat. Current sitation is that > ACLs still include the symbolic owner and not the numeric owner. > > This is quite trivial to fix: > > Replace all ocurences of "val = acl_to_text(acl, &len);" by "val = > acl_to_any_text(acl, 0, ',', ( > numeric_owner_option?TEXT_NUMERIC_IDS:0));" and followed by > "len=strlen(val);" after the "if (!val)" error-handling. > > > Effect: Numeric owner is stored. > > I'd like to note that this improvement is essential to me. Why? Star introduced the -numeric option in 1993 to work in create list and extract mode. The ACL Support introduced in 2001 was created to behave in a similar way. If gtar does the same, the best way would be to use -numeric in extract mode. > (2a) tar archive creation without "--numeric-owner" option: > > In GNU tar 1.26, for every file the owner is stored both, symbolic and > numeric. I would expect that ACLs are stored in both ways, too. star > shows us how to do that: > > star stores the numeric owner in a forth field of an acl: (e.g. > "u:msteinbo:rwx:500"). Correct, this is an extension to the ACL format that was needed to allow ACLs to be archivable in a reliable way at all. > (2b) tar extract should use the 4th field (discussed in point 2) in > presence of "-numeric-owner". > > This together with point (2) enabled users to restore an backup created > without numeric owner option on a clean hard disc without passwd entries > for the users (let's assume that /etc/passwd is contained in the archive > so the operation makes sense). > > I'd like to mention that this point would increase star compatibility a lot. If there is not such behavior, the gtar implementation is of limited usablility. There are two use cases: 1) File servers that do not import nam services. This is rare toway with NFSv4 2) Deleted user credentials for old employees. This is something that happens frequently. 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
[Bug-tar] ACL support in git version of GNU tar
Hi everybody, Today I noticed that GNU tar (git master) now supports XATTRs, ACLs and SELINUX-Attributes. I am really pleased to read this in "git log". Congratualtions for this improvement. The improvements do not break star und redhat tar compatibility. Having used Redhats patch for many years now (and an improved version which I made), I am able to enumerate a few points that IMHO need improvement: (1) tar archive creation with "--numeric-owner" option: In this case, users are expectiing that the archive does not contain any symbolic owner name, so it can be extracted to an emoty hard disc on a system bootet e. g. by a rescue cd from Redhat. Current sitation is that ACLs still include the symbolic owner and not the numeric owner. This is quite trivial to fix: Replace all ocurences of "val = acl_to_text(acl, &len);" by "val = acl_to_any_text(acl, 0, ',', ( numeric_owner_option?TEXT_NUMERIC_IDS:0));" and followed by "len=strlen(val);" after the "if (!val)" error-handling. Effect: Numeric owner is stored. I'd like to note that this improvement is essential to me. (2a) tar archive creation without "--numeric-owner" option: In GNU tar 1.26, for every file the owner is stored both, symbolic and numeric. I would expect that ACLs are stored in both ways, too. star shows us how to do that: star stores the numeric owner in a forth field of an acl: (e.g. "u:msteinbo:rwx:500"). (2b) tar extract should use the 4th field (discussed in point 2) in presence of "-numeric-owner". This together with point (2) enabled users to restore an backup created without numeric owner option on a clean hard disc without passwd entries for the users (let's assume that /etc/passwd is contained in the archive so the operation makes sense). I'd like to mention that this point would increase star compatibility a lot. Optional (3): Do not store ACLs iff ACL contains just the normal user, group and other permissions, i. .e. the ACL is an compatibility ACL. What is your opinion on these points? Greetings from Germany Markus Steinborn GNU gv maintainer PS: "iff" is the usual abbreviation for "if and only if" and not a typo.
