[OE-core] About pseudo's chmod

[Seebs]

On 1 Aug 2016, at 0:57, Robert Yang wrote:

> Sorry, the steps were wrong, they should be:
> 1) Out of pseudo:
>    $ umask 0022
>    $ touch file1
> 2) Under pseudo:
>    $ ln file1 file2
>    $ chmod 777 file2
>    $ ls -l file1 file2
>    We can see that both file1 and file2's mode is 0777.
>    But if we remove file2:
>    $ rm -f file2
>    $ ls file1
>    Now file1's permission is 0755, not 0777 or 0644, it should be 0777 
> here.

The short answer is: If you aren't tracking a file in pseudo, we don't 
make promises about its behavior. Normally, we don't touch them, but if 
there's hard links to them that are being touched, well. And having a 
hard link that is tracked, and another that isn't, is probably 
impossible to support. I definitely don't want to keep database entries 
for files that have been deleted, that way lies madness and possible 
database corruption; for instance, if we do that, and you make a new 
file of the same type, it'll show up as having those permissions, with 
only a path-mismatch warning in the database to suggest what went wrong.

I would say that the probable correct answer is either "make the 
original file be tracked" or "don't use hard links in this case".

Note that, under older pseudo, the file would have ended up 0777. The 
behavior of silently masking out 022 from underlying filesystem 
permissions is entirely intentional. During some debugging quite a while 
back, we discovered a quirk in oe-core, plus a strange behavior of
GNU tar, which between them resulted in some sstage directories getting
unpacked with mode 0777.

And we *really* don't want the build system generating files which other 
users can modify, especially not in stuff that's intended to go into a 
root filesystem. So stripping out those bits in the underlying 
filesystem is intentional.

If you were actually root, yes, the original file would have its mode 
changed to 0777. But we should never be *caring* about the mode bits on
raw files outside of pseudo, except that we want them to allow owner
write permissions and not allow group or other write permissions. If the
file's permissions matter to the build system or generated stuff, the
file should be tracked by pseudo.

-s