Page MenuHomePhabricator

[llvm-objcopy] Change handling of output file permissions
ClosedPublic

Authored by abrachet on May 31 2019, 12:31 AM.

Details

Summary

Address bug 42082 where files were always outputted with 0775 permissions. Now, the output file is given either 0666 or 0777 if the object is executable.

Diff Detail

Repository
rL LLVM

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
abrachet added inline comments.Jun 5 2019, 12:16 AM
llvm/tools/llvm-objcopy/llvm-objcopy.cpp
188 ↗(On Diff #203091)

This may not be permanent, I am trying to add ObjectFile::isExecutableObject() here https://reviews.llvm.org/D62838

Context isn't available in some of the regions; can you reupload the patch w/ context?

Using arc automatically includes full context, but if you upload patches manually, you should format your patch w/ -U99999 as described here: http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface

llvm/test/tools/llvm-objcopy/ELF/execute-permissions.test
1 ↗(On Diff #203091)

I believe umask (as a shell command and as a syscall) is only available on linux, so these will need guards to be excluded on windows.

  • In lit, you can use # UNSUPPORTED: windows to exclude it
  • In the code, you should put the umask calls in a #ifndef _WIN32 block.
2 ↗(On Diff #203091)

Instead of invoking clang, just use dummy files created by yaml2obj (see other tests in this directory)

4 ↗(On Diff #203091)

I think this also needs a # REQUIRES: shell, although maybe using ls/stat instead is possible (e.g. pipe ls into FileCheck and expect "rwxrwxrwx"

llvm/test/tools/llvm-objcopy/ELF/respect-umask.test
15 ↗(On Diff #203091)

Use cmp instead of diff

llvm/tools/llvm-objcopy/llvm-objcopy.cpp
222 ↗(On Diff #203091)

I guess what I was picturing is just having the method restoreStatOnFile that preserves dates and permissions, and have that method be called twice for the regular file and the dwo file.
But, I don't think the split dwo feature is ever used w/ executables, so it might be fine to always assume 0666 permissions for that.

227 ↗(On Diff #203091)

Although the earlier check guarantees that -p is never used with - as an output file, I think it makes sense to have this check first in the method, with a brief comment on why it's being skipped.

230 ↗(On Diff #203091)

I think this actually looks correct, although you need the umask call (and corresponding headers) guarded to exclude windows.
The right place to put it would be in the support library (same place as sys::fs::setPermissions), and just make it noop for the Windows implementation. IMO since this would be the first call to umask, it's fine to leave it here with a TODO to move it into libSupport when someone else needs it.

According to man umask, the umask syscall can never fail, so there is no error handling needed, although perhaps a comment that it is not threadsafe would be good.

255 ↗(On Diff #203091)

Binary input (see BinaryELFBuilder::initFileHeader()) currently hardcodes to ET_REL, so this should stick with the default of false.

270 ↗(On Diff #203091)

(from the archive writing portion hidden in the context)
Have you looked at how GNU objcopy handles permissions in archives? The archive code creates a NewArchiveMember struct for each object copied, and has a Perms field which currently defaults to 0644; I imagine we should do the similar logic for that too (i.e. either 0666/0777 depending on the executable bit). You probably don't need to do any umask magic for that; the umask should be handled during archive extraction.

abrachet updated this revision to Diff 203286.Jun 5 2019, 10:54 PM

Changed restoreDateOnFile to a more general restoreStatOnFile which also handles permissions. New archive members also get their permissions set based on isExecutableFile()

abrachet marked 8 inline comments as done.Jun 5 2019, 10:59 PM
abrachet added inline comments.
llvm/tools/llvm-objcopy/llvm-objcopy.cpp
214 ↗(On Diff #203286)

Removing the space between (void) and ::umask was clang-formats doing, but I figured I would keep it and ask here. I couldn't find references to calling functions in the global namespace, or unused results in the style guide.

abrachet marked an inline comment as done.Jun 5 2019, 11:04 PM
abrachet added inline comments.
llvm/tools/llvm-objcopy/llvm-objcopy.cpp
231 ↗(On Diff #203286)

We could have -p preserve permissions ignoring both the umask and whether or not it is an executable object. Although it is a little bit strange to have --preserve-date do this too, but I figured I would suggest while we are working on this now.

jhenderson added inline comments.Jun 6 2019, 3:35 AM
llvm/test/tools/llvm-objcopy/ELF/invalid-preserve-dates.test
1 ↗(On Diff #203286)

This test (and the corresponding behaviour in the code) feels like it belongs in a separate patch to me.

rupprecht marked an inline comment as done.Jun 6 2019, 10:23 AM
rupprecht added inline comments.
llvm/test/tools/llvm-objcopy/ELF/execute-permissions.test
13–14 ↗(On Diff #203286)

The copy is unnecessary, just call llvm-objcopy %p/Inputs/alloc-symtab.o %t1

llvm/tools/llvm-objcopy/llvm-objcopy.cpp
214 ↗(On Diff #203286)

Usual style for unused variables/return values is void w/ no space, so this looks correct.

276–280 ↗(On Diff #203286)

... I should have realized this earlier, but maybe we don't need the umask calls at all if we can just refactor some things:

  • If you add some plumbing for the FileBuffer permissions, i.e. make FileBuffer::FileBuffer() take unsigned Flags as a constructor param (0 as a default), then
  • Within FileBuffer, create the FileOutputBuffer w/ permissions passed in to the constructor instead of always passing FileOutputBuffer::F_executable, then
  • Reorder these calls like thus:
object::Binary &Binary = *BinaryOrErr.get().getBinary();
Exec = isExecutableObject(Binary);
FileBuffer FB(Config.OutputFilename, Exec ? FileOutputBuffer::F_executable : 0);
if (Error E = executeObjcopyOnBinary(Config, Binary, FB))
  return E;

Then I think the permissions should be fine (FileOutputBuffer happens to use 0666/0777 based on that one bit, which matches what we want), including handling umask (handled by the OS when creating files)

abrachet updated this revision to Diff 203407.Jun 6 2019, 12:02 PM
abrachet retitled this revision from [llvm-objcopy] Change output file permissions to be the same as the input file to [llvm-objcopy] Change handling of output file permissions.
abrachet edited the summary of this revision. (Show Details)

Removes checks that both input and output files are not stdin and stdout when --preserve-date (to be added in a seperate patch). Significantly simplifies the changing of permissions, now done on opening the file which will also respect the umask.

abrachet marked 5 inline comments as done.Jun 6 2019, 12:05 PM
rupprecht accepted this revision.Jun 6 2019, 2:36 PM

Just a couple nits, but I think this is ready to commit now. It can be updated whenever D62838 lands. Thanks for all the iterations!

llvm/tools/llvm-objcopy/Buffer.h
50 ↗(On Diff #203407)

"explicit" can be removed now that this is two-args (and there's no implicit-conversion risk)

llvm/tools/llvm-objcopy/llvm-objcopy.cpp
152 ↗(On Diff #203407)

Can you add a TODO to use isExecutableObject from D62838 once that's submitted?

154 ↗(On Diff #203407)

getEType() == ELF::ET_EXEC

This revision is now accepted and ready to land.Jun 6 2019, 2:36 PM
abrachet updated this revision to Diff 203457.Jun 6 2019, 3:03 PM
abrachet edited the summary of this revision. (Show Details)

Added a TODO and slight change to isExecutableObject

abrachet marked 3 inline comments as done.Jun 6 2019, 3:06 PM
abrachet added inline comments.
llvm/tools/llvm-objcopy/Buffer.h
50 ↗(On Diff #203407)

I quickly checked if this was still the case because of the default arg, explicit does still protect here. Can be seen here if curious https://godbolt.org/z/nAlqDq

rupprecht marked an inline comment as done.Jun 6 2019, 3:30 PM
rupprecht added inline comments.
llvm/tools/llvm-objcopy/Buffer.h
50 ↗(On Diff #203407)

Yep! Of course, I forgot about default args affecting that.

MaskRay requested changes to this revision.Wed, Jun 19, 1:10 AM

I believe GNU objcopy has the following logic:

  if (i_ehdrp->e_type == ET_EXEC)
    abfd->flags |= EXEC_P;
  else if (i_ehdrp->e_type == ET_DYN)
    abfd->flags |= DYNAMIC;

// bfd/opncls.c
static inline void
_maybe_make_executable (bfd * abfd)
{
  /* If the file was open for writing and is now executable,
     make it so.  */
  if (abfd->direction == write_direction
      && (abfd->flags & (EXEC_P | DYNAMIC)) != 0)
    {
      struct stat buf;

      if (stat (abfd->filename, &buf) == 0
	  /* Do not attempt to change non-regular files.  This is
	     here especially for configure scripts and kernel builds
	     which run tests with "ld [...] -o /dev/null".  */
	  && S_ISREG(buf.st_mode))
	{
	  unsigned int mask = umask (0);

	  umask (mask);
	  chmod (abfd->filename,
		 (0777
		  & (buf.st_mode | ((S_IXUSR | S_IXGRP | S_IXOTH) &~ mask))));
	}
    }
}

I would not suggest copying this behavior (if ET_EXEC or ET_DYN, chmod +x).
Instead, mirroring the input file's permissions is much more reasonable and gives the least surprise.

This revision now requires changes to proceed.Wed, Jun 19, 1:10 AM

Instead, mirroring the input file's permissions is much more reasonable and gives the least surprise.

@MaskRay, do you think that it should directly mirror the input file's permissions or should it do it as close as possible while respecting the umask?

We have 3 choices.

  1. cp -p semantics: perm(output) = perm(input)
  2. cp semantics: perm(output) = perm(input) & ~umask
  3. GNU objcopy (also linker behavior): perm(output) = (ET_EXEC || ET_DYN ? 0777 : 0666) & ~umask

Respecting umask is nice, so I'll go with 2) or 3).

The argument for 2) is: if the input shared object does not have executable bit,
after llvm-objcopy, we do not have to fix up the permission bits.

I don't hate 3) as much as I did before, but still feel we can't do it cleanly. If it is a block/character special file, you probably don't want to change its permission (think: root does llvm-objcopy something /dev/null).

I think I agree that 2 is our best option here. I think perhaps overlooked is when reading from stdin we don't know what permissions to assign. What I am working on right now just assigns 0775 (the current default for all output files) I don't know if you would think this is worth checking if the object file is marked as executable or not.

If it is a block/character special file, you probably don't want to change its permission (think: root does llvm-objcopy something /dev/null).

I'm not sure I understand why this is specifically a problem for 3. Perhaps sys::fs::setPermissions (and other routines in sys::fs:: which modify set permission bits) should be changed to be weary about the file's type, but I don't understand why this is specifically a problem for 3. Seems like a problem for every option including how llvm-objcopy currently does this.

I think I agree that 2 is our best option here. I think perhaps overlooked is when reading from stdin we don't know what permissions to assign. What I am working on right now just assigns 0775 (the current default for all output files) I don't know if you would think this is worth checking if the object file is marked as executable or not.

If it is a block/character special file, you probably don't want to change its permission (think: root does llvm-objcopy something /dev/null).

I'm not sure I understand why this is specifically a problem for 3. Perhaps sys::fs::setPermissions (and other routines in sys::fs:: which modify set permission bits) should be changed to be weary about the file's type, but I don't understand why this is specifically a problem for 3. Seems like a problem for every option including how llvm-objcopy currently does this.

Sorry, the issue about block/character special file is generic, not specific to 3). Let's see what other reviewers think.

abrachet updated this revision to Diff 205745.Thu, Jun 20, 12:28 AM

Output files now mirror input file permissions while respecting the umask.

abrachet marked an inline comment as done.Thu, Jun 20, 12:30 AM
abrachet added inline comments.
llvm/test/tools/llvm-objcopy/ELF/mirror-permissions.test
12 ↗(On Diff #205745)

I know this won't be allowed, it was just to ask for help on how to do this. I don't want to make the entire test unsupported on Windows just because umask needs to be 0 on systems which have such a thing.

I think this looks pretty good, but I'd like D63583 to land first if possible.

llvm/test/tools/llvm-objcopy/ELF/mirror-permissions.test
1 ↗(On Diff #205745)

Add a comment at the top of this test that explains what the aim of the test is.

12 ↗(On Diff #205745)

I agree that this probably isn't the right way of doing things, and checking the permissions on Windows is important. How about having two tests, one for Windows and one for Linux? Effectively you already have that, just add REQUIRES: windows to this test and delete this block.

abrachet updated this revision to Diff 205945.Fri, Jun 21, 12:19 AM

Split tests into Windows and Unix versions.

If it is a block/character special file, you probably don't want to change its permission (think: root does llvm-objcopy something /dev/null).

I think we have 3 ways of addressing this:

  1. Add flags to various file handling routines in sys::fs to be weary to not change permissions of a special file.
  2. Ignore this because it is very unlikely.
  3. Not changing permissions of the output file if it is being written over.

I had actually started on 1, but think that it was not worth it, it just clutters their parameters for very little reason. Ultimately I think the problem here is very unlikely for this and other llvm tools. I don't remember the last time I ran anything as su, nor do I think any setuid program would have any reason run llvm-objcopy or any other llvm tools. I think 3 is the obvious compromise, checking if we are writing to a special file is too niche to worry about in my opinion, but not changing permission bits of an existing file would solve the concern raised in a straight forward manner. Personally I am the biggest fan of 2 for the reasons above, I'm not sure that the benefits of 3 outweigh the cost of adding what would be confusing behavior in my opinion.

If it is a block/character special file, you probably don't want to change its permission (think: root does llvm-objcopy something /dev/null).

I think we have 3 ways of addressing this:

  1. Add flags to various file handling routines in sys::fs to be weary to not change permissions of a special file.
  2. Ignore this because it is very unlikely.
  3. Not changing permissions of the output file if it is being written over.

    I had actually started on 1, but think that it was not worth it, it just clutters their parameters for very little reason. Ultimately I think the problem here is very unlikely for this and other llvm tools. I don't remember the last time I ran anything as su, nor do I think any setuid program would have any reason run llvm-objcopy or any other llvm tools. I think 3 is the obvious compromise, checking if we are writing to a special file is too niche to worry about in my opinion, but not changing permission bits of an existing file would solve the concern raised in a straight forward manner. Personally I am the biggest fan of 2 for the reasons above, I'm not sure that the benefits of 3 outweigh the cost of adding what would be confusing behavior in my opinion.

2 should be fine..

jhenderson accepted this revision.Fri, Jun 21, 2:11 AM

LGTM, with the suggested comment changes, but please wait for the other patch, and @MaskRay's agreement.

llvm/test/tools/llvm-objcopy/ELF/mirror-permissions-unix.test
4 ↗(On Diff #205945)

You could probably combine this comment paragraph with the initial one.

llvm/test/tools/llvm-objcopy/ELF/mirror-permissions-win.test
4 ↗(On Diff #205945)

This should have a comment explaining why this test is Windows-specific.

rupprecht accepted this revision.Fri, Jun 21, 5:47 PM

(ditto that Ray should take another look, but looks mostly fine to me)

llvm/tools/llvm-objcopy/llvm-objcopy.cpp
221–226 ↗(On Diff #205945)

Once you land D63583, you should be able to make Stat a const parameter again, since setPermissions will be taking care of masking Stat.permissions().

246 ↗(On Diff #205945)

0777

(the umask should be what masks other/world permissions)

284 ↗(On Diff #205945)

0666

abrachet updated this revision to Diff 206107.Fri, Jun 21, 5:53 PM

Changed default permissions when reading from stdin.

abrachet marked 4 inline comments as done.Fri, Jun 21, 5:53 PM
abrachet added inline comments.
llvm/tools/llvm-objcopy/llvm-objcopy.cpp
246 ↗(On Diff #205945)

Great, thanks!

jhenderson added inline comments.Mon, Jun 24, 1:55 AM
llvm/test/tools/llvm-objcopy/ELF/mirror-permissions-unix.test
4 ↗(On Diff #206107)

"The Unix version..."

Why might the tests fail? Be a bit more explicit (specifically, they might fail because the user has a different umask to the build bots).

llvm/test/tools/llvm-objcopy/ELF/mirror-permissions-win.test
4 ↗(On Diff #205945)

Still missing this comment... It'll largely be the same as the Linux one, just inverted.

llvm/test/tools/llvm-objcopy/ELF/mirror-permissions.test
1 ↗(On Diff #206107)

I think you accidentally re-added this file?

abrachet updated this revision to Diff 207189.Sat, Jun 29, 1:11 AM
abrachet marked an inline comment as done.

Added comments to tests.

abrachet marked 4 inline comments as done.Sat, Jun 29, 1:14 AM
abrachet added inline comments.
llvm/test/tools/llvm-objcopy/ELF/mirror-permissions-unix.test
4 ↗(On Diff #205945)

You could probably combine this comment paragraph with the initial one.

I separated these because the initial one is explaining the entire test but the second comment is explaining the # UNSUPPORTED: system-windows. Do you still think I should combine them, I don't have a large preference.

jhenderson accepted this revision.Mon, Jul 1, 3:02 AM

LGTM. @MaskRay should approve before this gets committed though.

llvm/test/tools/llvm-objcopy/ELF/mirror-permissions-unix.test
4 ↗(On Diff #205945)

This is fine now. The extra detail makes it a more meaningful independent paragraph.

MaskRay accepted this revision.Mon, Jul 1, 4:18 AM
This revision is now accepted and ready to land.Mon, Jul 1, 4:18 AM
This revision was automatically updated to reflect the committed changes.
phosek added a subscriber: phosek.Thu, Jul 4, 9:53 PM

This broke tests:

FAIL: LLVM :: tools/llvm-objcopy/ELF/respect-umask.test (31512 of 32250)
******************** TEST 'LLVM :: tools/llvm-objcopy/ELF/respect-umask.test' FAILED ********************
Script:
--
: 'RUN: at line 8';   touch /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 9';   chmod 0755 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 10';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0755
: 'RUN: at line 11';   chmod 0500 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 12';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0500
: 'RUN: at line 13';   chmod 0555 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 14';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0555
: 'RUN: at line 16';   /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/bin/yaml2obj /b/s/w/ir/k/llvm-project/llvm/test/tools/llvm-objcopy/ELF/respect-umask.test -o /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 18';   umask 0022
: 'RUN: at line 19';   chmod 0777 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 20';   /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/bin/llvm-objcopy /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1
: 'RUN: at line 21';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1 | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms
: 'RUN: at line 22';   cmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0755
: 'RUN: at line 24';   umask 0237
: 'RUN: at line 25';   chmod 0707 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 26';   /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/bin/llvm-objcopy /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1
: 'RUN: at line 27';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1 | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms
: 'RUN: at line 28';   cmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0500
: 'RUN: at line 30';   umask 0222
: 'RUN: at line 31';   chmod 0777 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 32';   /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/bin/llvm-objcopy /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1
: 'RUN: at line 33';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1 | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms
: 'RUN: at line 34';   cmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0555
--
Exit Code: 1

Command Output (stderr):
--
yaml2obj: Error opening '/b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp': Permission denied

--

********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Testing Time: 105.45s
********************
Failing Tests (1):
    LLVM :: tools/llvm-objcopy/ELF/respect-umask.test

  Expected Passes    : 23888
  Expected Failures  : 63
  Unsupported Tests  : 8298
  Unexpected Failures: 1
[557/559] Linking CXX executable tools/clang/unittests/Tooling/ToolingTests
FAILED: test/CMakeFiles/check-llvm

Even after the fix r365170 the tests are still failing.

This broke tests:

FAIL: LLVM :: tools/llvm-objcopy/ELF/respect-umask.test (31512 of 32250)
******************** TEST 'LLVM :: tools/llvm-objcopy/ELF/respect-umask.test' FAILED ********************
Script:
--
: 'RUN: at line 8';   touch /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 9';   chmod 0755 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 10';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0755
: 'RUN: at line 11';   chmod 0500 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 12';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0500
: 'RUN: at line 13';   chmod 0555 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 14';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0555
: 'RUN: at line 16';   /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/bin/yaml2obj /b/s/w/ir/k/llvm-project/llvm/test/tools/llvm-objcopy/ELF/respect-umask.test -o /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 18';   umask 0022
: 'RUN: at line 19';   chmod 0777 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 20';   /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/bin/llvm-objcopy /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1
: 'RUN: at line 21';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1 | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms
: 'RUN: at line 22';   cmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0755
: 'RUN: at line 24';   umask 0237
: 'RUN: at line 25';   chmod 0707 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 26';   /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/bin/llvm-objcopy /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1
: 'RUN: at line 27';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1 | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms
: 'RUN: at line 28';   cmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0500
: 'RUN: at line 30';   umask 0222
: 'RUN: at line 31';   chmod 0777 /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp
: 'RUN: at line 32';   /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/bin/llvm-objcopy /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1
: 'RUN: at line 33';   ls -l /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1 | cut -f 1 -d ' ' > /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms
: 'RUN: at line 34';   cmp /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp1.perms /b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp.0555
--
Exit Code: 1

Command Output (stderr):
--
yaml2obj: Error opening '/b/s/w/ir/k/recipe_cleanup/clangz_eJan/llvm_build_dir/test/tools/llvm-objcopy/ELF/Output/respect-umask.test.tmp': Permission denied

--

********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Testing Time: 105.45s
********************
Failing Tests (1):
    LLVM :: tools/llvm-objcopy/ELF/respect-umask.test

  Expected Passes    : 23888
  Expected Failures  : 63
  Unsupported Tests  : 8298
  Unexpected Failures: 1
[557/559] Linking CXX executable tools/clang/unittests/Tooling/ToolingTests
FAILED: test/CMakeFiles/check-llvm

Even after the fix r365170 the tests are still failing.

Fixed by rL365172.

The umask 02* tests do not work, so I deleted them for now.

Thanks you @phosek and @MaskRay. I really don't know how these worked on my machine, I'm never in su! Sorry about that.