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

[madoga]

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?

Thank you

Best Regards,

Mario

[Mark Hatle]

Post by madoga
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
 # Fix the permission, owner and group of 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
        #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.)

--Mark

Post by madoga
Thank you
Best Regards,
Mario

--

[Mark Hatle]

Post by madoga
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
# Fix the permission, owner and group of 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
#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

Post by madoga
Thank you
Best Regards,
Mario

--