[ELDK] [RFSB] cpio fails Permission denied

[Wolfgang Denk]

Dear Martin,

In message <47F3F98010FF784EBEE6526EAAB078D10635E6F3 at tq-mailsrv.tq-net.de> you wrote:
> 
> > i try to build a rootf with the rfsb as a normal user.
> > Now, when i choose the httpd application or the linux-utils
> > i get an permission denied from cpio because the files the command
> > try to copy are owned by root.
> > These are all files that were changed at the installation of the
> > ELDK42 by the FIXOWNER Script cause the suid bits are set.
> > 
> > I can change the owner of the Files and solve this Problem. But is
> > this the right way? ELDK_FIXOWNER changes this before with the reason
> > which is described in the DULG.
> 
> I experienced the same problem with the 
> crosstool-targetcomponents-armVFP_trg-0.43-3 package. And I'm also
> wondering what will be the best way to solve this (I suppose there
> are many other packages which are concerned by this).

Well, the problem is simple and straightforward: ELDK_FIXOWNER sets
ownerships and permissions as needed to export the ELDK installation
as root file system over NFS.  This includes making some files owned
by root and set with permissions that prevent reading them as an
ordinary user.

So when you want to read these files there are exactly two options:

1) Do not run the commands that need to read these files as ordinary
   user; this would mean to run the "make" or at least thge "cpio"
   with root permissions (say, under control of "sudo").

   If you ask for my opinion: I do not consider this a good idea.

2) Make sure to set ownership and permissions of these files such that
   they can be read by you; this would mean that they are not suitable
   any more for exporting as a root file system, i. e. you need _two_
   installations of the ELDK: one for use as a root file system (here
   you need to run the ELDK_MAKEDEV and ELDK_FIXOWNER scripts), and
   another one as base for building file system images (here you do
   not need to and actually must not run these scripts).

Agreed, such a duplicated installation is not really elegant, but disk
space is cheap these days, and having a separate, clearly controlled
environment for software production purpores clearly has some benefits
as well.

My recommendation is to go with b).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any sufficiently advanced bug is indistinguishable from a feature.
                                                      - Rich Kulawiec