[yocto] [OE-core] FILESYSTEM_PERMS_TABLE / fs-perms.txt

[Mark Hatle]

On 12/10/18 4:14 AM, madoga wrote:
>> On 12/5/18 11:12 AM, madoga wrote:
>>
>>> Hello List,
>>> I am trying to configure my entire filesystem by using FILESYSTEM_PERMS_TABLES
>>> variable pointing to my custom fs-perms.txt, but it does not work. While I
>>> debugged package.bbclass looking for any error or failure, I found something
>>> strange with os.chmod & os.lchown methods (at function fix_perms):
>>> # Fix the permission, owner and group of path
>>> def fix_perms(path, mode, uid, gid, dir):
>>> if mode and not os.path.islink(path):
>>> #bb.note("Fixup Perms: chmod 0%o %s" % (mode, dir))
>>> os.chmod(path, mode)
>>> # -1 is a special value that means don't change the uid/gid
>>> # if they are BOTH -1, don't bother to lchown
>>> if not (uid == -1 and gid == -1):
>>> #bb.note("Fixup Perms: lchown %d:%d %s" % (uid, gid, dir))
>>> os.lchown(path, uid, gid)
>>> I have hardcoded mode variable to “0333”, just for testing: os.chmod(path,
>>> 0o333)and I have seen that permissions were been configured into a “0711”. Also
>>> I am going to ask about os.lchown, due to my filesystem is still been owned by
>>> my user and my group.
>>> Does anyone have an idea about what is going on? Has somebody have the same
>>> problem?
>>
>> The commands run under the pseudo environment. Pseudo captures these commands
>> and stores them in a database it can 'replay' at any time.
>>
>> It only make them in the actual filesystem if permitted by the host.
>>
>> You must look at the filesystem results in the live system (running pseudo) or
>> in the results of the build -- otherwise what you are looking at is not valid.
>>
>> (BTW this is the reason that the commended code was left in that function. In
>> case something is wrong, just remove the comments and you'll get notes on what
>> it is doing to help debug. This shouldn't be necessary unless you are
>> developing the function itself.. but that is why they are there.)
>>
> 
> Thank you for your reply Mark!

pseudo replaces fakeroot.  Fakeroot can't capture some of the items that are
needed [and a few other reasons).

> Does the pseudo environment allow to set the entire rootfs by using fakeroot? Perhaps this is not the right way to make it, I am not pretty sure about that. I would like to obtain my rfs with a concrete permissions when bitbake finishes, folders, executables... Is there another/better way to accomplish?

psuedo is just a LD_PRELOAD library that is connected to a database that
captures permissions changes to files..

> About debbuging bb.notes, I have already removed the comments and everything seems working OK.

This tells me that it's likely working properly and you are not in the pseudo
environment.  You need to be in that loaded environment with the correct
database attached to look at the set permissions.  Any task in the system
prefixed by 'fakeroot' will do this for you.

--Mark

> Best Regards,
> Mario
> 
>> --Mark
>>
>>> Thank you
>>> Best Regards,
>>> Mario
> 
>