What are the real risk you talk about? There are no significant
risks that I can see. Risk is commonly defined as:
probability of event occurrence X consequences of the event
occurring.
So:
- 10% probability resulting in death in not acceptable
- 10% risk of missing lunch is probably acceptable to most
people
- 0.001 % risk of losing a non-critical file is probably
acceptable
So far since I started the project I don't think anyone has ever
reported an actual problem that occurred due to LTIB having sudo
access. I'm not saying it could not happen, but believe the risk
and consequences to be very low.
The point is that things need to be kept in proportion. As I said
before, what could happen? bear in mind any of your work should be
checked into an SCM and you machine backed up. If you (or your ID
department) are not doing this, then they are taking unnecessary
risks.
Sudo is needed so that you correctly populate an NFS mountable root
filesystem. You, may not use NFS for development but many people
do, it's the most efficient way to develop, time-wise.
If this is a real problem for you then either use a different
builder/project, or provide a solution to the mailing list. As I
said before if you are doing this type of development at some time
you'll need sudo, regardless of LTIB.
Regards, Stuart
On 05/07/12 19:32, Jehan Bing wrote:
Hi all,
I would have liked to be able to run LTIB without the sudo
requirements too. We went with the 3rd option ("common sense").
That said, here are my 2 cents and bike-shed opinion...
On 2012-07-05 00:52, Stuart Hughes wrote:
Do you have sudo on these machines
(outside of LTIB), if not, they're
not suitable for installing LTIB. If they do, LTIB presents no
more
risk that the users allowed to run sudo.
I think the point is that a user shouldn't need to run sudo at
all.
It's fine for the initial install of LTIB, the IT team can do it,
though I don't see why it is a necessity either.
And for regular usage, root is required to run rpm, but why?
As for users who already have sudo access (or at least a lax
enough one giving rpm access doesn't bring a bigger security
risk), those are not the target of this discussion.
If they want reason, the simple one is
that an NFS root area cannot be
correctly populated without sudo permissions (for rpm install).
I'm not sure I get the link between having NFS and running LTIB.
In our case we don't use NFS.
If the don't like that there options are:
* Deny your request and offer an non-IT PC where you can do
LTIB: the
cost a few hundred dollars
Multiplied by the number of developers. For a small company, it
can add up quickly.
Or the computer needs to be shared, which means a bigger
more-expensive machine, and allowing the sharing is not
necessarily a trivial task depending one's network setup and the
way the developer are organized.
Plus a non-IT PC can have is whole set of issues (access to the
SCM server, to the source package repository, possibly even
Internet, ...) which then go back to your point #2 about spending
many hours and thousands of dollars to work-around them.
* Deny your request and have you spend
many hours (thousands of dollars)
trying to work-round this. You will ultimately fail as you'll
need to
be root at some point if you're doing this kind of development.
But why do we need root at any point? Is there a technical reason?
Or is it just inertia about what LTIB can and cannot do today?
The only reason real need for root that I see in my somewhat
limited knowledge of LTIB, is to set the correct file ownership in
the firmware but fakeroot should allow to do that without
requiring root on the host machine.
Is there anything else that really need root?
* Allow your request and let common sense
prevail. If they have
concerns they should be based on something objective - a real
security
concern. Ask them what they think could happen?
With sudo on rpm, an ill intentioned developer can do whatever he
wants on the host machine by installing the "right" software. So
the machine needs to be isolated and that cost time and money.
So right now, LTIB is a tradeoff between time/money and security
risks. But I don't see why this tradeoff is really necessary
(well, except that time/money is also required to fix it)
|