ltib
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stuart Hughes
Subject: Re: [Ltib] How to use LTIB w/o root?
Date: Tue, 09 Jun 2009 16:08:42 +0100
User-agent: Thunderbird 2.0.0.16 (X11/20080707) 
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). 




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. 




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). 

Regards, Stuart
reply via email to
[Prev in Thread] Current Thread [Next in Thread]