[PATCH] package.bbclass: Remove redundant chmod/chown operations

[PATCH] package.bbclass: Remove redundant chmod/chown operations

[Phil Blundell]

These were introduced in 6021e309e69d823e1467648aee12a32182945569.  The
code currently reads:

                os.link(file, fpath)
                fstat = cpath.stat(file)
                os.chmod(fpath, fstat.st_mode)
                os.chown(fpath, fstat.st_uid, fstat.st_gid)

which can have no useful effect since, if "fpath" is a hard link to
"file", it will (by definition) have the same mode, uid and gid.

Signed-off-by: Phil Blundell <philb@gnu.org>
---
 meta/classes/package.bbclass |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 4136a9f..99eda77 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1000,9 +1000,6 @@ python populate_packages () {
             fpath = os.path.join(root,file)
             if not cpath.islink(file):
                 os.link(file, fpath)
-                fstat = cpath.stat(file)
-                os.chmod(fpath, fstat.st_mode)
-                os.chown(fpath, fstat.st_uid, fstat.st_gid)
                 continue
             ret = bb.utils.copyfile(file, fpath)
             if ret is False or ret == 0:
-- 
1.7.10.4

Re: [PATCH] package.bbclass: Remove redundant chmod/chown operations

[Mark Hatle]

On 5/2/13 8:20 AM, Phil Blundell wrote:
> These were introduced in 6021e309e69d823e1467648aee12a32182945569.  The
> code currently reads:
>
>                  os.link(file, fpath)
>                  fstat = cpath.stat(file)
>                  os.chmod(fpath, fstat.st_mode)
>                  os.chown(fpath, fstat.st_uid, fstat.st_gid)
>
> which can have no useful effect since, if "fpath" is a hard link to
> "file", it will (by definition) have the same mode, uid and gid.

I thought there were filesystems where a link operation can result in different 
file permissions, owners and groups.  It's rare, but umask and effective uid/gid 
could play a part in this.  (Mind you all of the operations should be happening 
when pseudo is running and should mask that behavior.)

> Signed-off-by: Phil Blundell <philb@gnu.org>
> ---
>   meta/classes/package.bbclass |    3 ---
>   1 file changed, 3 deletions(-)
>
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index 4136a9f..99eda77 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -1000,9 +1000,6 @@ python populate_packages () {
>               fpath = os.path.join(root,file)
>               if not cpath.islink(file):
>                   os.link(file, fpath)
> -                fstat = cpath.stat(file)
> -                os.chmod(fpath, fstat.st_mode)
> -                os.chown(fpath, fstat.st_uid, fstat.st_gid)
>                   continue
>               ret = bb.utils.copyfile(file, fpath)
>               if ret is False or ret == 0:
>

Re: [PATCH] package.bbclass: Remove redundant chmod/chown operations

[Phil Blundell]

On Thu, 2013-05-02 at 08:41 -0500, Mark Hatle wrote:
> On 5/2/13 8:20 AM, Phil Blundell wrote:
> > These were introduced in 6021e309e69d823e1467648aee12a32182945569.  The
> > code currently reads:
> >
> >                  os.link(file, fpath)
> >                  fstat = cpath.stat(file)
> >                  os.chmod(fpath, fstat.st_mode)
> >                  os.chown(fpath, fstat.st_uid, fstat.st_gid)
> >
> > which can have no useful effect since, if "fpath" is a hard link to
> > "file", it will (by definition) have the same mode, uid and gid.
> 
> I thought there were filesystems where a link operation can result in different 
> file permissions, owners and groups.  It's rare, but umask and effective uid/gid 
> could play a part in this. 

I can't think of any POSIX-conformant systems where this would be true.
1003.1 §3 is fairly clear that file permissions are a property of the
file, not of the link(s) to it, which would prohibit different links
from having different modes or owners.

Can you give a concrete example of such a scenario?

p.