Re: About pseudo's chmod

[Robert Yang <liezhi.yang@windriver.com>]

On 08/01/2016 04:42 PM, Seebs wrote:
> 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".

Hi Peter,

How about we track the src when hardlink, for example:

$ ln oldpath newpath

Track both oldpath and newpath. The patch for pseudo is:

diff --git a/ports/unix/guts/linkat.c b/ports/unix/guts/linkat.c
index ec27e47..521b8fa 100644
--- a/ports/unix/guts/linkat.c
+++ b/ports/unix/guts/linkat.c
@@ -62,6 +62,10 @@
           * if the thing linked is a symlink.
           */
          pseudo_client_op(OP_LINK, 0, -1, -1, newpath, &buf);
+        /*
+         * Track oldpath in case it isn't tracked.
+         */
+        pseudo_client_op(OP_LINK, 0, -1, -1, oldpath, &buf);

          errno = save_errno;

// Robert

>
> 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