Date: Mon, 9 Feb 2004 12:28:15 +0100 (CET) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Tim Kientzle <kientzle@acm.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Odd ACL question Message-ID: <20040209122341.S32427@beagle.fokus.fraunhofer.de> In-Reply-To: <40269DF5.2090806@acm.org> References: <4025A0DD.2010607@acm.org> <20040208134125.L28775@beagle.fokus.fraunhofer.de> <40269DF5.2090806@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Feb 2004, Tim Kientzle wrote: TK>On Sat, 7 Feb 2004, Tim Kientzle wrote: TK>>Joerg Schilling's "star" archives ACLs as follows: TK>> TK>>"user::rwx,group::r--,group:mail:rw-:6,mask::rw-,other::r--" TK>> TK>>Note the "group:mail:rw-:6" entry that contains a fourth TK>>field with the uid/gid number. ... TK>> TK>>Question: Is this a useful extension? TK> TK>Harti Brandt responded: TK>> It definitely is. Joerg and I had several hours of talk on this issue. TK>> If you, for example, restore on a system that usually gets its passwd from TK>> YP or LDAP and you don't have it available ... TK> TK>Ah. That's the example I needed. Now to figure out how to implement TK>such functionality; hacking the acl library functions may TK>not be the best approach, but I'm equally dismayed by the prospect TK>of duplicating the acl library functions in my code. ;-( TK> TK>> As far as I know there are options to star that let you select the exact TK>> behaviour in these cases. TK> TK>This is one difference between 'star' and my work: 'star' offers TK>a great deal of control over the archiving/dearchiving TK>process; my work tries to remove the need for such control TK>by using intelligent algorithms. For example, bsdtar/libarchive TK>doesn't require you to specify the compression when reading archives; TK>it determines it automatically. TK> TK>In this case, I'm considering: TK> * If the username exists, use that. TK> * If the username does not exist and the UID is not already in TK> use, issue a warning and use the UID. TK> * If the username exists and the UID conflicts with the local TK> system, ??? TK> TK>This last case is the tough one. My temptation: map it to TK>an unused UID, issue a warning about the remap, and keep going. That may cause the problem I described. This may leave a file in a user directory that the user cannot delete without intervention of the root user, but its probably the simplest solution. What about non-existing groups? I remember talking with Joerg about this, but cannot remember the outcome of this. You may want to ask him. TK>There are certainly rare cases where manual control is TK>needed. That's why I'm pleased that 'star' is available TK>in ports. ;-) Are you going to replace that horrible thing called GNU tar in the bases system? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040209122341.S32427>