Re: [Duplicity-talk] Errors during test phase of installation.....

[edgar . soldin]

hey Ken,

just checked. OSX uses bsdtar 2.8.3, at least between 10.9 and 10.12.

-p option behaves identical to gnutar. 
when run as root it tries to restore owners and permissions.
when run as ordinary user it only restores the permissions as far as possible, 
ignoring a setup umask.

in conclusion i don't think OSX is at fault here, but i assume it is simply a 
user error.

..ede/duply.net

On 05.02.2017 18:14, Kenneth Loafman wrote:
> The tests don't run as root, so not sure what you mean by "as root on linux". 
>   The -p option would cause tar to try and make the target owner the same as 
> the original, not the test user, which I'm sure would break things.  Lots of 
> moving parts, and since some of them move relative to ownership of the file, 
> and system platform, it would take a while to untangle.  MacOS is different 
> from Linux is different from BSD.  Root has different defaults than a normal 
> user.
> 
> I think a lot of this lies in the BSD'ness of the MacOS vs Linux.
> 
> ...Ken
> 
> 
> On Sun, Feb 5, 2017 at 10:21 AM, <address@hidden <mailto:address@hidden>> 
> wrote:
> 
>     Ken,
> 
>     i just wonder if
>     - setting a proper umask
>     - switching to the proper user
>     beforehand would mitigate the extraction issue, if it is the initial 
> extraction at all.
> 
>     also there is this tar switch, from the manpage 
> https://www.gnu.org/software/tar/manual/tar.html 
> <https://www.gnu.org/software/tar/manual/tar.html>
>     "
>     `--preserve-permissions'
>     `--same-permissions'
>     `-p'
> 
>         When tar is extracting an archive, it normally subtracts the users' 
> umask from the permissions specified in the archive and uses that number as 
> the permissions to create the destination file. Specifying this option 
> instructs tar that it should use the permissions directly from the archive. 
> See section Setting Access Permissions.
>     "
> 
>     i see your issue with the 'rm -rf' below, but i guess what rm is doing 
> there as root on linux is probably not posix at all and chmod-ing your target 
> beforehand would be expected.
> 
>     ..ede
> 
>     On 05.02.2017 17:08, Kenneth Loafman wrote:
>     > I'll let Scott answer for El Capitan, but for Sierra, here's the
>     > reproduction.
>     >
>     > On MacOS Sierra:
>     >
>     > address@hidden:~$ mkdir -p foo/bar
>     > address@hidden:~$ rm -r foo
>     > address@hidden:~$ mkdir -p foo/bar
>     > address@hidden:~$ chmod 0000 foo/bar
>     > address@hidden:~$ rm -r foo
>     > rm: foo/bar: Permission denied
>     > rm: foo: Directory not empty
>     > address@hidden:~$ rm -rf foo
>     > rm: foo/bar: Permission denied
>     > rm: foo: Directory not empty
>     >
>     > On Linux:
>     >
>     > address@hidden:~$ mkdir -p foo/bar
>     > address@hidden:~$ rm -r foo
>     > address@hidden:~$ mkdir -p foo/bar
>     > address@hidden:~$ chmod 0000 foo/bar
>     > address@hidden:~$ rm -r foo
>     > rm: descend into write-protected directory 'foo/bar'? y
>     > rm: remove write-protected directory 'foo/bar'? y
>     > address@hidden:~$ rm -rf foo
>     >
>     > It's a fairly major difference if you expect 'rm -rf' to remove 
> everything
>     > you own.  This happens in two tests in
>     > testing/functional/test_selection.py, TestLockedFoldersNoError, lines 
> 982
>     > and 999, at the statements 986 and 1005, thus the check for platform 
> before
>     > those tests.
>     >
>     > ...Ken
>     >
>     >
>     > On Sun, Feb 5, 2017 at 7:28 AM, edgar.soldin--- via Duplicity-talk <
>     > address@hidden <mailto:address@hidden>> wrote:
>     >
>     >> On 04.02.2017 00:23, Scott Hannahs via Duplicity-talk wrote:
>     >>> The other big error was that the un-tar of the test files would set 
> file
>     >> permissions and owners so that the test user could not delete them.   
> I set
>     >> a note that the testing phase has to run as root.  It shouldn’t but 
> that
>     >> seems to be an issue.  If the no-owner no-group flags were set on the 
> untar
>     >> command for the test directories it might work.  But that may mess up 
> some
>     >> of the tests.
>     >>
>     >> Scott,
>     >>
>     >> can you explain this a little bit more detailed? do you mean that
>     >> untar-ing the duplicity tarball creates files/folders with improper
>     >> permissions?
>     >>
>     >> what do those improper persmissions/owner values look like?
>     >>
>     >> ..ede/duply.net <http://duply.net>
>     >>
>     >> _______________________________________________
>     >> Duplicity-talk mailing list
>     >> address@hidden <mailto:address@hidden>
>     >> https://lists.nongnu.org/mailman/listinfo/duplicity-talk 
> <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>     >>
>     >
> 
>