|
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 ifyou 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 bulkstorage as I don't think the Savannah project (http://savannah.nongnu.org/projects/ltib) would be the rightplace to stage the 12GB of download area. Why are you paranoid what do you fear?.I was just concerned because1) 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. Thewhois 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
[Prev in Thread] | Current Thread | [Next in Thread] |