Re: [Ltib] How to use LTIB w/o root?

[Ryan Nowakowski]

On Tue, Jun 09, 2009 at 04:08:42PM +0100, Stuart Hughes wrote:
> Hi Grant,
>
> Grant Edwards wrote:
>> On Tue, Jun 09, 2009 at 09:05:26AM +0100, Stuart Hughes wrote:
>>
>>> I need to correct a misunderstanding.  LTIB needs you to setup
>>> sudo root access for rpm (to build an NFS mountable area with
>>> the devices, owners, permissions etc).  However you are only
>>> ever running as root during the install phase of rpm building.
>>
>> Yes, I'm aware of that.
>>
>>> Not only that, but there are many checks to make sure that
>>> ltib cannot write outside your project area.  Does that
>>> reassure you or do you still have concerns?
>>
>> I'd still be more comfortable if root access wasn't required.
>> It seems to be something that's been managed by other build
>> systems (e.g. OE, uclinux-dist, buildroot) -- though I'm not
>> sure exactly how they do it.
>
> It's a compromise.  On those system IIRC you can only build a  
> RAMdisk/JFFS image and so you don't have to be root as  
> genext2fs/mkfs.jffs2 doesn't need root access to make the image.  The  
> downside though is you can't incrementally deploy while NFS mounted,  
> which I find a big productivity boost (./ltib -p strace for example).

Maybe LTIB could be modified to run in 2 different modes.  One mode that
just produces the RAMdisk/JFFS image and doesn't require root access.
The other mode runs as root to allow NFS deployment(the current mode).

>>> Note that on popular distros like Ubuntu a normal user is
>>> automatically enabled to run any command as 'sudo root' and
>>> that seems to be universally accepted.
>>
>> Without a password?
>
> Yes, xandros (eee pc) IIRC.  Maybe Ubuntu (I can't recall).  But in any  
> case if you allow a user root access (even with a password) a simple  
> slip at the command line will wipe out your disk.

Ubuntu by default allows normal users to have sudo access to everything
but requires the user to type in their password when using sudo.

>>> From my point of view there are 2 security issues running as
>>> root:
>>>
>>> 1/ Malicious access by unauthorised users.  I discount this
>>>    because whether you're root or not if you have physical
>>>    access to a machine, you can pull disks out or simply
>>>    reboot with 'init=/bin/sh' and do what you want anyway.
>>
>> True.
>>
>>> 2/ Accidental destruction, e.g. 'sudo rm -rf * /' (I
>>>    accidentally hit a space), or a program malfunctions.  In
>>>    the case of LTIB, there have so far never been any reports
>>>    of accidental deleting of files outside the project area.
>>>    I thought about this carefully and there are extensive    
>>> safeguards in LTIB.  The code is there for you to check if
>>>    you like.
>>
>> I'm more concerned about bugs in the install and post-install
>> scripts in the RPM spec files.  One presumes those are running
>> with root privledges?
>>
>
> For the install section, it's not a problem, there's a guard at the top  
> of all spec files to prevent this, also ltib checks the actually install  
> patch for all files before it proceeds.
>
> You have a good point for the post-install sections though.  I should  
> put a check into ltib's spec file parser to disallow these.  For cross  
> compiled systems they're doomed to failure and so should not be present.  
>  I'll add this to my TODO list.
>
>
>>> I am behind bitshrine.org.  It was setup to provide bulk
>>> storage as I don't think the Savannah project  
>>> (http://savannah.nongnu.org/projects/ltib) would be the right
>>> place to stage the 12GB of download area.  Why are you
>>> paranoid what do you fear?.
>>
>> I was just concerned because 
>>
>>  1) I've had uniformly miserable experiences with development
>>     software from silicon vendors in the past.  That's the one
>>     thing in the industry that seems to have been a constant
>>     over the past 25 years.  I'd be rather hesitant to use LTIB
>>     if Freescale or NXP has any significant influence over the
>>     project.
>
> I understand your concerns, but in this case I can assue you that what  
> comes from bitshrine/savannah is open.
>
>>
>>     One presentation on LTIB I found was very explicit about
>>     how Freescale controls all of the packages and all packages
>>     have to be submitted to and approved by Freescale.  While
>>     that's OK for something used on an eval board, I don't
>>     think that's acceptible for production use.
>
> That's not true.  For their own content it goes through internal QA and  
> approval before it gets pushed out to bitshrine.org/gpp (which is a good  
> thing).  However, for community developers that have write access to the  
> project, you can upload content to  
> http://bitshrine.org/cgi-bin/gpp_upload.cgi this records who uploaded  
> it, the license and confirms it's freely distributable.  I think this is  
> important as all the origins of the source (every patch included) can be  
> verified by looking at the info files that get stored with the upload  
> (see for example:  
> http://bitshrine.org/gpp_info/linux-2.6.15-ep93xx-gao33.patch.html)
>
>>      2) I could find no indication who owned bitshrine.org.  The
>>     whois results showed it to be a "hidden" registration (only
>>     the hosting company's name was available).
>>
>
> The ISP I use controls all that stuff, I think they have some kind of  
> automatic "privacy guard".
>
>>> LTIB is a completely open project.
>>
>> Thank you for your reassurances.
>>
>
> BTW everyone: please note that all target types are welcome, so if you  
> have a  board that is not in LTIB but you do have a working  
> kernel/kernel-config (e.g. source) and a cross-toolchain it's very  
> simple to add your target (it can be as simple as 3 new files: main.lkc,  
> kernel-xxx.spec.in and linux-2.x.yyyy.config).