Re: [yocto] [OE-core] FILESYSTEM_PERMS_TABLE / fs-perms.txt
On Monday, 10 de December de 2018 17:12, Mark Hatle
wrote:
> 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..
>
What do I need to use Yocto under a pseudo environment?
The problem I was describing before was without using LD_PRELOAD and LD_PREFIX.
Now, I have added both into my local.conf:
LD_PRELOAD = "/usr/lib/x86_64-linux-gnu/pseudo/libpseudo.so"
LD_PREFIX = "/usr/"
But BitBake doesn't like it and I cannot find to much information about this
issue...
Thank you!
Mario
> > 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
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] FILESYSTEM_PERMS_TABLE / fs-perms.txt
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
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] FILESYSTEM_PERMS_TABLE / fs-perms.txt
> 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!
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?
About debbuging bb.notes, I have already removed the comments and everything
seems working OK.
Best Regards,
Mario
> --Mark
>
> > Thank you
> > Best Regards,
> > Mario
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] FILESYSTEM_PERMS_TABLE / fs-perms.txt
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.)
--Mark
>
> Thank you
>
> Best Regards,
>
> Mario
>
>
>
>
>
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [OE-core] FILESYSTEM_PERMS_TABLE / fs-perms.txt
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--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
