Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fedora 12 Package Installation Policy Tightened

kdawson posted more than 4 years ago | from the tougher-by-default dept.

Red Hat Software 172

AdamWill writes "After the controversy over Fedora 12's controversial package installation authentication policy, including our discussion this week, the package maintainers have agreed that the controversial policy will be tightened to require root authentication for trusted package installation. Please see the official announcement and the development mailing list post for more details."

cancel ×

172 comments

Sorry! There are no comments related to the filter you selected.

Finally! (3, Funny)

Rantastic (583764) | more than 4 years ago | (#30170396)

It's about time they fixed that.

Re:Finally! (4, Funny)

Cylix (55374) | more than 4 years ago | (#30170424)

I liked for the ability for users to manage my box.

Surely the users would never do anything that would harm the system in which we all exist?!?

Re:Finally! (1)

2.7182 (819680) | more than 4 years ago | (#30170494)

This controversy story is definitely a controversy.

Re:Finally! (5, Funny)

Icegryphon (715550) | more than 4 years ago | (#30170606)

I mean come on!
It took like a whole 24hrs from when a story was posted on slashdot.
What are they Microsoft?
Bunch of dirty hippie linux slackers

Re:Finally! (3, Insightful)

Anonymous Coward | more than 4 years ago | (#30171126)

they havent fixed it yet

Re:Finally! (1)

nexxuz (895394) | more than 4 years ago | (#30171710)

Bunch of dirty hippie linux slackers

It's Fedora not Slack!

Re:Finally!Pre-Christmas gift, shoes,handbags,ugg (-1, Offtopic)

rewfdytyiukfgherewre (1682734) | more than 4 years ago | (#30170666)

http://www.coolforsale.com/ [coolforsale.com] Christmas is around the corner: And old customers can also enjoy the gifts sent by my company in a can also request to our company. Gifts lot,Buy more get the moreOnly this site have this treatmentOur goal is "Best quality, Best reputation , Best services". Your satisfaction is our main pursue. You can find the best products from us, meeting your different needs. Ladies and Gentlemen weicome to my coolforsale.com.Here,there are the most fashion products . Pass by but don't miss it.Select your favorite clothing! Welcome to come next time ! Thank you! http://www.coolforsale.com/productlist.asp?id=s76 [coolforsale.com] (Tracksuit w) ugg boot,POLO hoody,Jacket, Air jordan(1-24)shoes $33 Nike shox(R4,NZ,OZ,TL1,TL2,TL3) $35 Handbags(Coach lv fendi d&g) $35 Tshirts (Polo ,ed hardy,lacoste) $16 free shipping competitive price any size available accept the paypal Thanks

Re:Finally!Pre-Christmas gift, shoes,handbags,ugg (0)

Anonymous Coward | more than 4 years ago | (#30171098)

Wow, actual spam on Slashdot. Don't think I've ever seen that before.

Re:Finally!Pre-Christmas gift, shoes,handbags,ugg (1)

Tim C (15259) | more than 4 years ago | (#30171422)

It (or similar) has been showing up on pretty much every story I've read on here for the last few days.

Re:Finally! (1, Insightful)

Anonymous Coward | more than 4 years ago | (#30171132)

I actually think the devs originally had it right to some degree. At least the problem they point out is real:

"From a more general perspective, the end effect of putting up a lot of
dialogs:

Root password [ ]
[ OK ]

is that you are training users to blindly enter the root password and
hit OK, *not* something that enhances the overall security of the
system."

Most of the times I have fixed a worm infested windows machine of a friend it wasn't an exploit that was to blame but the person had installed it themselves. Devs have trained users to respond to a password box in the following way: Type in their password and press enter.

Now if my flatmates/friends were used to installing software from the official repos without being prompted for root then if they were prompted it would have some effect. Possibly make them give me a call first.

Re:Finally! (0)

Anonymous Coward | more than 4 years ago | (#30171304)

What would you rather them do? Give you a call each time they encounter such a dialog, and have you come over and vet every little thing they want to install?

Re:Finally! (0)

Anonymous Coward | more than 4 years ago | (#30171620)

Yes,

AC First post? (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30170400)

AC First post?

Re:AC First post? (0)

Anonymous Coward | more than 4 years ago | (#30170498)

FAIL

Attitude (5, Insightful)

Island Admin (1562905) | more than 4 years ago | (#30170486)

What really got me about this one was the attitude some developers had ... constantly trying to justify their correctness, despite the huge backlash from users. I feel the trust relationship is kinda broken ... but at least they finally came around and listened.

Re:Attitude (1)

dburkland (1526971) | more than 4 years ago | (#30170568)

I agree, the level of arrogance was a little astounding (evident in both posts from the developer and Red Hat employees). I am glad however that they came around and listened to the people (even though it took a while).

sound (0)

Anonymous Coward | more than 4 years ago | (#30171146)

The pulse audio cramfest was even worse.

Re:Attitude (1)

AdamWill (604569) | more than 4 years ago | (#30172038)

"(even though it took a while)"

Um. The comment on the bug report which kicked all this off - "Seems to work: but why am I not getting a root password prompt?" - is dated 2009-11-18 07:47:19 EDT. The email announcing that the policy will be tightened is dated Thu, 19 Nov 2009 21:29:19 (again ET). That's a response time of 37 hours, 42 minutes, by my count. I think you'd find that's...really quite fast. :)

Re:Attitude (3, Interesting)

ByOhTek (1181381) | more than 4 years ago | (#30170634)

Nonetheless, it's not a *horrible* concept, it was just a little too loose (as I've seen it described).

I think, as an option, and if the user was within a certain group (such as sudoers/wheel/whatever - changeable by the admin, and users who have administrative access), and only signed packages were affected (no change there), I wouldn't see an issue. At that point, it's basically saying "don't require a password for sudo when installing a package trusted by trusted authority 'xyz'".

Re:Attitude (1)

imakemusic (1164993) | more than 4 years ago | (#30172132)

Nonetheless, it's not a *horrible* concept, it was just a little too loose (as I've seen it described).

Hur hur hur....

Re:Attitude (1)

ByOhTek (1181381) | more than 4 years ago | (#30172612)

I'm not even sure how that's applicable...

Should I just self-wooosh?

It's nothing new from them. (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#30170638)

The Fedora and Red Hat camp has always been pretty clueless. That's probably why they're one of the most popular distros out there. They've done a great job at appealing to the morons and fucktards of the Linux community.

Had somebody within the Debian, Slackware, FreeBSD, NetBSD, OpenBSD, or OpenSolaris communities suggested what Fedora implemented, they would have been publicly humiliated and disgraced forever on mailing lists and newsgroups.

I can just imagine Theo tearing some idiot five or six new assholes just for even suggesting the idea, let alone actually doing it.

Re:It's nothing new from them. (0)

Anonymous Coward | more than 4 years ago | (#30171900)

Yay, a troll!

They've done a great job at appealing to the morons and fucktards of the Linux community.

Aww, how cute! Ain't you the cuddly one.

Re:Attitude (0)

Anonymous Coward | more than 4 years ago | (#30171002)

I am glad that developers tried to justify their correctness. It took some time to get to where we could see what we could agree upon. We also have a better understanding of the desktop environment now. Just one more necessary step towards world domination of desktop linux.

Re:Attitude (2, Insightful)

Tim C (15259) | more than 4 years ago | (#30171442)

To be honest that's kind of what I've come to expect from most FOSS projects - an attitude of "we're doing this because we want to, we donate our time for free - if you don't like it, fork it and fix it, or use something else".

It's actually hard to argue with most of the time, as they really are donating their time for free...

Re:Attitude (3, Interesting)

dejanc (1528235) | more than 4 years ago | (#30171960)

What really got me about this one was the attitude some developers had ... constantly trying to justify their correctness, despite the huge backlash from users. I feel the trust relationship is kinda broken ... but at least they finally came around and listened.

Fedora does this all the time (or at least, often enough for me to think it's all the time). Here is a couple of examples:

  • Fedora Core 2 included the infamous 4k stack option enabled in Kernel, because of which NVIDIA drivers didn't work (and os drivers sucked). Users complained to no avail - Fedora's developers decided to introduce a feature they thought was good at cost of breaking many desktops. We had to recompile kernels.
  • Fedora 9 introduced new GDM. This application was (and still is) crippled compared to the old one, but apparently a major rewrite was in order. The result was that configuration of many users (e.g. autologin, etc) was broken, that there was no configuration GUI that we were used to, usability was crippled for all systems that use remote login with many users, etc. But, new GDM was the future, so despite the breakage, Fedora's developers decided to push it.
  • PulseAudio, anyone? But that's common for most distributions...

My point is: Fedora is a polygon for testing new technologies to be included in RHEL. Nothing more, nothing less. Perfect users for it are RHEL admins who want to get a preview of future releases, not casual desktop users.

That was close... (1)

Jawn98685 (687784) | more than 4 years ago | (#30170514)

...the package maintainers have agreed that the controversial policy will be tightened to require root authentication for trusted package installation.

Wow. Thank goodness those guys "discovered" that allowing non-root users to do dangerous things to the OS/application stack was a bad idea and "agreed" to lock it down. We might have had some serious problems there. (roll eyes)
WTF? How on gawds green earth did this happen in the first place?

Re:That was close... (1)

Scutter (18425) | more than 4 years ago | (#30170576)

WTF? How on gawds green earth did this happen in the first place?

Seriously, it's not like the final release was a surprise. Non of the beta testers noticed it and thought it might be an issue?

Re:That was close... (2, Informative)

juhaz (110830) | more than 4 years ago | (#30170780)

Seriously, it's not like the final release was a surprise. Non of the beta testers noticed it and thought it might be an issue?

How would they? Beta packages are unsigned, and this thing only works on signed packages.

Re:That was close... (1)

prefect42 (141309) | more than 4 years ago | (#30171228)

Not that I have a Beta to hand to check this, but you're saying that they sign Rawhide packages, but don't sign Beta packages? I find this highly unlikely, to the extent I'd guess you just made this up.

Re:That was close... (1)

juhaz (110830) | more than 4 years ago | (#30171298)

Not that I have a Beta to hand to check this, but you're saying that they sign Rawhide packages, but don't sign Beta packages? I find this highly unlikely, to the extent I'd guess you just made this up.

At what point did I say that they sign Rawhide packages? They don't.

Re:That was close... (1)

prefect42 (141309) | more than 4 years ago | (#30171458)

In which case I've lost my mind and apologise. I took the first RPM from rawhide 0xFFFF-0.3.9-4.fc12.x86_64.rpm and tested to see if it was signed. It was, but this doesn't seem to be universal, so you're right, and I'm entirely wrong.

Re:That was close... (2, Informative)

AdamWill (604569) | more than 4 years ago | (#30172456)

In which case I've lost my mind and apologise. I took the first RPM from rawhide 0xFFFF-0.3.9-4.fc12.x86_64.rpm and tested to see if it was signed. It was, but this doesn't seem to be universal, so you're right, and I'm entirely wrong.

Most packages in the current 'Rawhide' are still packages from the final F12 release, and hence signed. If you check a package with an fc13 tag - i.e. one built since F12 went out - you'll see it's not signed. There was a full package set rebuild during the F12 cycle, before the beta release, so by the time F12 Beta came out, just about every package in Rawhide had been rebuilt since F11's release, and hence was unsigned.

Re:That was close... (2, Insightful)

A beautiful mind (821714) | more than 4 years ago | (#30172020)

This is a good lesson in why a beta/staging environment should be as close to the real stuff as possible.

I hope they start signing beta packages with beta keys in the future...

Re:That was close... (1)

AdamWill (604569) | more than 4 years ago | (#30172104)

Non of the beta testers noticed it and thought it might be an issue?

Nope, because packages in the development repositories are not signed until very shortly before release. No-one testing the beta would have seen this bug, because they'd never have installed a signed package.

Non-controversial (1)

SgtChaireBourne (457691) | more than 4 years ago | (#30170676)

Wow. Thank goodness those guys "discovered" that allowing non-root users to do dangerous things to the OS/application stack was a bad idea and "agreed" to lock it down. We might have had some serious problems there. (roll eyes) WTF? How on gawds green earth did this happen in the first place?

The use of the word "controversial" to describe the rollback to the original, more secure settings is bizarre, too. The failure here was the process and the people that must have worked to push through the weird settings that allowed everyone and their dog to install random 'signed' but unconfigured packages. That's something we'd expect from Microsoft employees, trainees, 'engineers' or 'researchers', not Red Hat staff or volunteers.

I notice that mono has shown up in the distro, too. When will managers learn about bringing posers bringing the One Microsoft Way into a project? Microsoft hasn't done much of any technology right during the time it's been around. Is it a wise choice to start letting that way of thinking spread and gut yet another fine distro?

Re:Non-controversial (2, Informative)

Antique Geekmeister (740220) | more than 4 years ago | (#30171108)

It wasn't "everyone and their dog". You basically had to be logged into the console. I confirmed that it didn't work via a normal SSH session last night, the first time I had access to a Fedora 12 machine, was confused by it, and resolved to look into it later. The announcement helped explain what I saw.

It was still a stupid move, but it explains why more people wouldn't have noticed it in beta testing: we'd have often been logged in via SSH from our desktops. The stupidity was in introducing a distinction between console access and remote shell access: it's an unnecessary finessing of the console login that just created confusion and a tempest in a teapot that wasted people's time.

Re:Non-controversial (1)

taoye (1456551) | more than 4 years ago | (#30171742)

What? My dog was installing packages on my computer? No wonder... I didn't think I forgot *that* much about last night to forget where this install of "Poodles Gone Wild" came from.

Dunno man, but (5, Insightful)

Giant Electronic Bra (1229876) | more than 4 years ago | (#30170688)

The whole Fedora Team's creation of and response to this issue creates very serious doubt in my mind about their ability to manage a distribution and their understanding of proper security policy. I think they've got to open up their decision making process more and learn to communicate better. An idea this bad should have been squashed 5 minutes after it was proposed instead of being allowed to actually make it into a released distribution.

At least it all shows that the community still ultimately calls the shots.

Re:Dunno man, but (1)

quickOnTheUptake (1450889) | more than 4 years ago | (#30172026)

I'm actually surprised by the way everyone here agrees that the devs were wrong.
I actually thought they had a fairly good point after reading one of their comments [linux-archive.org] (fifth one down, Bill Nottingham, 12:23):

Out of the box, a desktop user has the ability to shut down the machine.
This gives them the ability, out of the box, to:
- DoS everyone on it
- get a root shell
-- install whatever they want
-- put viruses on
- hell, slap in a livecd or USB key and reinstall the box

Point being that Fedora is designed for desktop users, and because of this the default configuration already allows a non-privileged user to do far worse to the machine than install trusted software.

Re:Dunno man, but (1)

Giant Electronic Bra (1229876) | more than 4 years ago | (#30172426)

I think it is a bad direction to go in with security policy in general.

Sure, the desktop user can shutdown the machine, etc. The issue is that the default packageKit no-password setup is a recipe for non-technical users to potentially blow their own left foot off. 99% of what one would like to guard against is simply accidental damage to the system. The other issue is once you have such a passwordless system in place someone will easily find a way to exploit it. In fact its pretty easy to do and certainly anyone knowledgeable enough to be authoring exploits will know how to do that.

There are some other ways in which I just disagree with the team's position on this. They argue that its better to "not train user's to click on things" but doing that by simply essentially making the default for everything "OK, do the dangerous thing" is not an answer! Maybe there is no answer, but popping up a dialog or showing a prompt and requiring a password is SOMETHING at least. It can't possibly be worse.

They say that they don't like the concept of each user's policy management being essentially scattered to the four winds in the form of whatever dialog's happen to come up here and there, but centralizing it into one unified policy manager isn't better. Normal users, and even fairly advanced users in a lot of cases, have no idea what the settings in such a manager mean because they aren't presented with any sort of context. At least when a dialog pops up the user is aware of the context within which the decision is being made. Nothing will ever force users to make good decisions or even informed decisions, but some control panel they will never find and if they do find it is just a big list of dry explanations and check boxes is not better. Sure, that manager needs to exist, but as the sole way to access that stuff its not a good design.

There may be no perfect way for things to work, but reducing the level of security to triviality is patently less desirable than not doing that. That the Fedora team could even entertain any other opinion seriously undermines my confidence in their ability to make good security decisions overall.

Re:Dunno man, but (1)

AdamWill (604569) | more than 4 years ago | (#30172302)

The initial change was discussed in public - on the PackageKit mailing list - and implemented over a year ago. PackageKit is an upstream project, used by multiple distributions, and this change was implemented in PackageKit (although, of course, the upstream author who proposed and coded the change works for Red Hat); it's come to light in Fedora 12 because it's the first distribution to actually use a version of PackageKit ported to PolicyKit 1.

I'm curious as to how you expect an idea to be "squashed 5 minutes after it was proposed" as a result of Fedora "open[ing] up their decision making process" - how does a more open process lead to faster decisions? In all the experience I've ever had, the result is true. Having an open review process - which Fedora does - results in slightly slower decisions but, hopefully, more ultimately correct ones. I know which I'd choose.

There are potential process improvements here - there's a proposal to have a consistent policy for privileges granted via PolicyKit, for instance - but it's really not as simple as 'open up their decision making process'. It's pretty darn open already.

Re:Dunno man, but (1)

Giant Electronic Bra (1229876) | more than 4 years ago | (#30172848)

Well, I don't know, but the RESULT is what most people get to judge by. The result was a pretty significant change in behavior that seems to have hit most users of FC kind of out of left field. Maybe the whole issue isn't specific to Fedora but it points out that some level of visibility of the consequences of changes, upstream or not, doesn't exist. From looking at the chatter on the mailing list it seems to me that people on the 'inside' were aware of the ramifications of the change and let it go through. Obviously they seriously misjudged what the wider community's desires were. These things happen, but in the security arena they probably shouldn't happen. I don't know what the fix is, but there needs to be some analysis within the team and I suspect the answer is going to be what should have been the obvious answer, don't step on the traditional security policy principles that have existed as expectations within the Linux community since the earliest days.

It will be interesting to see what the ultimate response is in terms of process. Hopefully it will stimulate some creative thinking.

Re:That was close... (0)

Anonymous Coward | more than 4 years ago | (#30170716)

"Many eyes" missed it.

Re:That was close... (1)

natet (158905) | more than 4 years ago | (#30171520)

I've found that developers make ridiculously poor system administration decisions. Something that seems acceptable to set up on a development machine is not necessarily something you'd want to do on a production system.

Never really thought this needed changing (5, Interesting)

lnlypaladin (617060) | more than 4 years ago | (#30170564)

See personally I never thought it would be in discussion whether to allow non-root users to install packages. In my opinion it's one of the great advantages of *nix systems as far as security goes. Even the distributions with the root user disabled to make it easier on a desktop user, like Ubuntu, still require use of the sudo command. It's one of the biggest reasons certain worms and drive by download techniques which crippled Microsoft OS's never worked on *nix systems.

Re:Never really thought this needed changing (1)

nxtw (866177) | more than 4 years ago | (#30170754)

It's one of the biggest reasons certain worms and drive by download techniques which crippled Microsoft OS's never worked on *nix systems.

Bullshit. Worms need not require a privileged user account to be effective. A process running as an unprivileged user can:

  • use the network freely
  • access and modify that user's files
  • have itself start at login
  • trick the user into granting it privilege
  • gain privileged access via a local exploit

Re:Never really thought this needed changing (1)

b4dc0d3r (1268512) | more than 4 years ago | (#30170946)

You have to admit, it's pretty hard to know in advance which distro you're on and which packages are going to be available, so you have to plan to try a whole pile of exploits before you find one that works. The biggest or most common vulnerabilities are usually found, fixed, and ready for update rather quickly, so the window of opportunity is smaller as well. If the attack fails, you're restricted to listening on high ports and any other potential damage is minimized.

So I'd say the fragmentation "problem" is what keeps *nix safe with fast updates a close second. You are correct in theory, but practice lags behind.

Re:Never really thought this needed changing (1)

nxtw (866177) | more than 4 years ago | (#30171448)

You have to admit, it's pretty hard to know in advance which distro you're on and which packages are going to be available, so you have to plan to try a whole pile of exploits before you find one that works.

Maybe. But diversity isn't so important when you have one or two very popular targets. And some distributions' packages have modified version information identifying the distribution. For example, Ubuntu's Firefox build includes the distribution name and version in the user agent. Furthermore, many desktop Linux installs come from live CDs that install a default set of packages.

The biggest or most common vulnerabilities are usually found, fixed, and ready for update rather quickly, so the window of opportunity is smaller as well.

I've never seen any conclusive evidence that vulnerabilities are frequently found soon after they are put into the code. There was a Linux vulnerability found this year that affected kernels 2.4 and 2.6, for example. How often do people check previous (frequently unsupported) versions of the code? How many security fixes do Red Hat and Novell backport to their enterprise distributions, which frequently run "old" software (relative to Ubuntu/Fedora)?

If the attack fails, you're restricted to listening on high ports and any other potential damage is minimized.

Damage to the operating system isn't a big deal. There are plenty of copies of most operating systems on the Internet, and if the operating system was already installed by an end-user once, he or she can simply install it again. A malicious program running as a normal user has access to the user's home directory, and from there can copy, modify, or delete that information, or perhaps manipulate the web browser to steal user input.

Re:Never really thought this needed changing (1)

AdamWill (604569) | more than 4 years ago | (#30172636)

How many security fixes do Red Hat and Novell backport to their enterprise distributions, which frequently run "old" software (relative to Ubuntu/Fedora)?

All fixes for known vulnerabilities in supported packages in supported releases. That's kind of a big part of the definition of 'support', really.

Re:Never really thought this needed changing (1)

nxtw (866177) | more than 4 years ago | (#30172788)

Yes; it was a rhetorical question. The fact that they have to do this means that vulnerabilites are often published and fixed well after the initial release of a package.

Re:Never really thought this needed changing (1)

geekboy642 (799087) | more than 4 years ago | (#30171118)

The first entry is not entirely true. Non-root processes are restricted from using low port numbers(1024, iirc). Also, if there's a correctly configured firewall on the machine, a non-root process is incapable of going around it.
Not that it would actually prevent any malware I know of from wreaking havoc, high port numbers are perfectly fine for sending email and talking to bot herders.

Re:Never really thought this needed changing (1)

nxtw (866177) | more than 4 years ago | (#30171208)

Non-root processes are restricted from using low port numbers(1024, iirc).

I wasn't concerned about listening, actually, just outgoing connections.

Also, if there's a correctly configured firewall on the machine, a non-root process is incapable of going around it.

How many desktop Linux users have firewalls that prevent untrusted processes from making outgoing TCP connections?

Re:Never really thought this needed changing (1)

Tim C (15259) | more than 4 years ago | (#30171562)

Non-root processes are restricted from using low port numbers(1024, iirc).

And? Just because SMTP servers traditionally listen on port 25 doesn't mean that my zombie mailer process has to; similarly clients making outgoing connections all use high-numbered ports anyway, whether they're malicious or not.

if there's a correctly configured firewall on the machine, a non-root process is incapable of going around it

Not entirely true - you can make a connection out to a known address, and have the controller on the other end send commands back down that channel. In fact, you'd have to connect out regardless of how connections are made back to the bot just to advertise your existence.

Not that it would actually prevent any malware I know of from wreaking havoc

Exactly! Restricting low port numbers is no help at all - all it can do is prevent me from running a process on a machine on say port 80, and tricking people to connect to my malicious site rather than the presumably trustworthy one that's being run by the admin. That's a very, very small level of protection.

Re:Never really thought this needed changing (1)

cynyr (703126) | more than 4 years ago | (#30171988)

if you look at iptables you can in fact block outbound connections as well. So yes you can lock down all ports/addresses the machine has no business talking on/too.

Re:Never really thought this needed changing (1)

Tim C (15259) | more than 4 years ago | (#30172116)

So for a general purpose machine, that needs to be able to do email, web, etc, how do you lock down connections out?

There's nothing to stop me from running my bot control software so that it is listening to port 80. Are you suggesting that I need to apply for permission to make outgoing connections to port 80 on a site-by-site basis?

You can make it more difficult for processes to dial out, but on a machine that can actually use the network, you can't make it impossible.

Re:Never really thought this needed changing (1)

lnlypaladin (617060) | more than 4 years ago | (#30171162)

I concede that you're correct about worms, however,
  • trick the user into granting it privilege
  • gain privileged access via a local exploit

I would argue that these two arguments are always valid since there will always be users who aren't paying attention or are ignorant of what's going on with their own machine, and because it's extremely difficult to find and fix every exploit in any large piece of software.

I would still argue that though a worm could flourish under a specific user's account, it would still allow the damage be contained to that one user's account. Would you agree?

Do you also challenge my point's validity concerning traditional viruses, activex drive-by downloads, and the like? If so, what advantage would there be for desktop users in not having root access for all users, in your opinion?

Re:Never really thought this needed changing (1)

nxtw (866177) | more than 4 years ago | (#30171340)

I would still argue that though a worm could flourish under a specific user's account, it would still allow the damage be contained to that one user's account. Would you agree?

That's true, and that's my point. It is the contents of user accounts that users care about. The difference between "a worm stealing all of a user's personal information, leading to identity theft" and "a worm stealing all of a user's personal information and breaking the operating system" isn't that significant after the user's personal information has been stolen. Reinstalling/re-imaging an operating system is trivial compared to repairing identity theft or losing important information. If my OS gets corrupted, things aren't so bad - there are copies of the OS on the Internet and on DVD.

Do you also challenge my point's validity concerning traditional viruses, activex drive-by downloads, and the like? If so, what advantage would there be for desktop users in not having root access for all users, in your opinion?

On a single user system, the advantage of running as a unprivileged user is somewhat exaggerated unless steps are taken to limit that user's privileges beyond the default (for example, by only allowing trusted processes to be executed.)

Re:Never really thought this needed changing (1)

taoye (1456551) | more than 4 years ago | (#30171846)

I couldn't agree more. If everything an attacker needs is in a user account, who cares about getting root access?

Re:Never really thought this needed changing (1)

NoYob (1630681) | more than 4 years ago | (#30171216)

Non-root users can't install in Windows either. The problem is that most Windows users run their machines as admins; hence, all the virus problems folks have in the Windows World.

Re:Never really thought this needed changing (1)

lnlypaladin (617060) | more than 4 years ago | (#30172098)

Actually, I would say that the biggest problem is that you can't really do much of anything if your user isn't admin level on a windows system. That's why almost every windows user is an administrator on the local machine. Even in enterprise level networks, this is the case with security vulnerabilities mitigated by group policies and patches.

On a *nix box a user can still install programs and use resources as long as it's not making changes outside that user's account. (i.e. restricted to that user's processes and home directory). On a windows machine, without administrative access you can't really do much more than access the internet and run maybe 1/4 of the programs available as long as they're already installed and aren't configured to do something goofy like access the registry or use a location outside the user's home directory or the system temp folders for doing file work.

Unfortunately, most windows programs seems to have been designed to expect administrative access in order to function properly even after installation

Re:Never really thought this needed changing (1)

digitalhermit (113459) | more than 4 years ago | (#30171306)

I agree with you completely that requiring root or sudo access is a good thing but the beauty of Unix and Linux is that I can install software without root privileges rather easily. Whether I extract a tarball into a fakeroot directory in my home dir or specify the same with rpm (or an rpmmacros file), it's usually trivial to install packages. What's not so trivial is to change the configuration of the host system. And I agree with you completely that requiring root or sudo access is a good thing.

This means I can install my dev environment, scripts, etc.. But if I, say, install a torrent client then *on a properly configured system* I won't get it to work. I.e., I have freedom to use the system without breaking anything. And that's a pretty good feeling knowing that I can't harm anything if I don't su to root.

Sure, there are exceptions, but for the most part I prefer the Unix way than the Microsoft way.

At the risk of being flamed to hell (1)

jimicus (737525) | more than 4 years ago | (#30170586)

The idea of allowing normal users to install signed software is actually not all that bad.

Frankly, the most common alternatives - either users have to ask IT to do it (which neither the users like nor does the IT department necessarily want to spend its days messing around with) or giving them local admin (or, this being Linux, local root) privileges are both awful.

Off the top of my head, I can think of a few sane solutions to the problem - none of which appear to have been given serious thought:

1. Provide a list of software which anyone can install. (Oh look, that's more or less what Fedora did, though obviously if you depend on signatures you don't need to compile and maintain a list. Might have been nice if they'd made it so the admin had to decide in advance what software could be allowed, rather than just sticking the entire repository in there, but the idea's sound)
2. Provide a sandbox of some sort that can be wiped on demand and install software into that.

Re:At the risk of being flamed to hell (1)

Junta (36770) | more than 4 years ago | (#30170652)

It is a horrible horrible horrible default. Provide the capability so those infrastructures that really want it can make an *informed* choice to do so, fine.

You don't have to give people *full* root privileges, you can selectively give them access through sudo to use a package installer that only works with signed packages. Though fedora emphasizes 'su' style privilege escalation which has no granularity, 'sudo' style gives the granularity required. The credential of 'oh, I happen to be at the 'local' screen' doesn't make sense for this sort of activity. On a desktop system absent of a larger administration team, the first and nearly always only users gets to be admin. In a larger environment, use group memberships to do this sort of thing, but in all cases prompt for the users password.

Fedora's overlooking sudo as a primary part of their privilege escalation strategy is a huge mistake in my opinion.

Re:At the risk of being flamed to hell (1)

AdamWill (604569) | more than 4 years ago | (#30172200)

Though fedora emphasizes 'su' style privilege escalation which has no granularity, 'sudo' style gives the granularity required.

Um. You didn't research this very thoroughly, did you?

The whole basis for the introduction of this issue is the use of PolicyKit, which is massively more flexible and fine-grained than su *or* sudo. Both su or sudo can only run entire processes as a different UID, and have fairly limited authentication method choices. PolicyKit allows far more fine-grained granting of escalated privileges; that's the whole point of using it in PackageKit, the main PackageKit GUI process runs as an unprivileged user and PolicyKit is used to grant escalated privileges only to a subsidiary process which actually does the package installation. PolicyKit also allows far more flexibility in terms of the exact type of authentication required for any given action.

Basically, PolicyKit has all the flexibility sudo has, and far far more. Seriously, go do some reading [freedesktop.org] .

Re:At the risk of being flamed to hell (5, Informative)

jedidiah (1196) | more than 4 years ago | (#30170724)

This is just nonsense, TOTAL NONSENSE.

Unix users have ALWAYS had the ability to install applications into their own home directory. Ok, so it (maybe) never occured to the authors of Linux package managers to target the users home directory. However, the fact remains that the ability/possibility has always been there. You simply don't need to pollute the system files in order to "install an app" on Unix. That is one of it's key strengths.

This is why the Fedora guys got skewered.

Some of us have been "installing applications" in our home directories since before the first line of Linux was written.

Re:At the risk of being flamed to hell (1)

Hurricane78 (562437) | more than 4 years ago | (#30171632)

This is by far the best comment in here.

Thank you for thinking outside that tiny box of a coming-from-windows mindset, that so many “new” people wrapped themselves in in the last years.

The saying “Those who do not learn the history, are doomed to reimplement it. Badly.” fits perfectly here.

It’s the same set of people who work so hard, so make KDE and Gnome virtually indistinguishable from the incredibly primitive UI of Windows. (In case you don’t know: Everything that still has monolithic applications [instead of following the UNIX philosophy to combine things that do one thing right], menus and clickable icons (instead of actually efficient UI structures), etc, is “incredibly primitive”. Windows is the prime example of that.)
It's so sad when you see Gnome and KDE “applications”, or things like OpenOffice, with tons of functions, in one huge single package. Instead of having sets of functions that a freely combinable for the needed purposes.

Think of a paintbrush “app”, that works on images, documents, and other files too, and is independent of the actual document code. THAT would be the UNIX philosophy applied to GUIs.

But nooo... there could be the possibility of some Windows user with his limited mindset loving us, because we”re different. So we must imitate Windows, and do everything right for him! Just pleaaase, you users, do love us!!

Now where have I heard this before.

Protip: No, this won’t give you love. Neither in software development, nor in dating or in school! You will only become the bottom bitch of those that you beg to. ^^

Re:At the risk of being flamed to hell (1)

mejogid (1575619) | more than 4 years ago | (#30172506)

Users have always had the ability to run apps in their home directory that *run with user privileges*. As this stands, there's nothing to stop a script installing a daemon that runs as root with a known exploit and running that exploit. If the application is within the user's home directory, there's no chance of it having privileges beyond that of the user in a properly configured system.

Re:At the risk of being flamed to hell (1)

fnj (64210) | more than 4 years ago | (#30171204)

I have one word for software which can be installed without root privelege:

ActiveX

Re:At the risk of being flamed to hell (1)

jdunn14 (455930) | more than 4 years ago | (#30171248)

I'll dive in burn with you on this one. You missed one other major point that the Fedora developers had. A large majority of their user base is desktop systems where there is not some great IT staff or distant administrator. I am the admin in my boxes. No one else has a login. If I want to install packages without a password that shouldn't be difficult. I configured the repositories, I added the public keys after evaluating how much I trusted the repo. Letting the normal user (still me) install packages isn't the end of the world people make it out to be. In the case where I let my friend log into my machine remotely to look at something or help me debug or whatever, they WOULD NOT be able to install packages unless they logged into the local console (yes that was part of this change).

All this said, I personally would not turn on this option for my own desktops because I don't like the idea of my unprivileged account being able to hose the OS. Then again, repairing/reinstalling the OS is not a big deal compared to replacing the files in /home.

What this all comes down to is that it is not nearly as cut-and-dried as people on either side are shouting that it is.

Re:At the risk of being flamed to hell (1)

foobat (954034) | more than 4 years ago | (#30172382)

someone mod this person up now.

I currently have a ticket open requiring the root password because "the user can't do what they want" or something similar. I tried to explain using sudo to them, but this seems beyond them. If i give them the root password it gets written onto a postit note on their monitor.

Even more controversial is the.... (0, Offtopic)

gatkinso (15975) | more than 4 years ago | (#30170604)

....photo on www.fedora.org.

Poor little weiner dog.

I used to like to go there to see the odd pics, but haven't been in a while.

Overreacting (0)

Anonymous Coward | more than 4 years ago | (#30170680)

Allowing non-root users (by default, though I'm sure you could enforce your own policy) isn't nearly as heart-stopping as people are claiming.

This is definitely an overreacting community - what's the harmed in SIGNED packages? Oh, boohoo, my users can install vim, emacs or pico if I neglected to. The horror!
Of course, there are some packages in repo that could be questionable (jtr? kismet? ettercap?) that definitely need to be considered.

At the end of the day, Fedora is still geared toward desktop use, so seriously... how "dangerous" could this really be on privately maintained systems with few users?

Obviously a bad idea for RHEL, but I wholly think everyone is severely overreacting on it's addition to Fedora.

Re:Overreacting (2, Insightful)

DiegoBravo (324012) | more than 4 years ago | (#30171406)

What about installing finger/telnet/etc?
What about installing sendmail and conflicting with the postfix installation?
What about installing 1Gb of maps for some random game?
What about updating a package that the admin knows will generate a conflict with other in-house application? (I don't know if updates were included in the policy, but is the same criteria)

Re:Overreacting (1)

MrSenile (759314) | more than 4 years ago | (#30171572)

--> What about installing finger/telnet/etc?

Have them listen on a new port. But honestly, if they want to run telnet, the security violations alone regarding it should cause them to cut off their own fingers.

--> sendmail and postfix installations

mail sysadmin@yourbox
Subject: Request
Dear sir/madam. I would like to have sendmail and/or postfix installed so that I can (blah blah blah)
Thank you.
.

--> 1G of maps and other crap
1. Do you have the quota? yes? Good, home directory it.
2. You do not have the quota?
mail sysadmin@yourbox
Subject: More Quota
Dear sir/madam. I would like to have more quota to install maps and/or some random game.
Thank you.
.

--> Updating packages that the admin knows will generate a conflict with other applications?
1. This brings up why you need this 'conflicting' application to begin with. A lot of times you don't even need it.
2. The solution will either run it yourself on a different port for your own use (which sounds like would be the issue) or...
mail sysadmin@yourbox
Subject: Application
Dear sir/madam. I would like to have package X installed. I know this conflicts with package Y.
If this is not feasible can you give me working alternatives?
Thank you.
.

There's reasons systems are ran by, system administrators. The same is said for windows servers. They don't allow users to install 'confliction applications' either or other centralized applications that require system access. Why should Linux be different?

If it's a workstation, you should already have root access, being said workstation owner.

If it's a friend's workstation and he was generious enough to grant you user access, assume it's a server, and your friend is the system adminstrator you need to contact.

I don't see a problem here.

KPackageKit (1)

Rik Sweeney (471717) | more than 4 years ago | (#30170700)

I have a similar complaint about KPackageKit. You can optionally choose to make it store your password so that you don't have to type it in when you next install or update packages. That's fair enough, if you trust that no one is going to install anything dodgy then that's OK. What I do take issue with is that this box is checked by default.

Granted I imagine most people might simply click this anyway but am I the only one who thinks this is a bit of an oversight?

Outrageous (3, Funny)

Anonymous Coward | more than 4 years ago | (#30170806)

TROLL:
Allowing users to conveniently install signed/authorized packages/software.This is LINUX dammit if you're not jumping through hoops to get something done you are DOING IT WRONG!.

RANT:
Non-root users will destroy EVERYTHING that's why they must be frustrated for the sake of SECURITY. That white-listed signed software package must be personally allowed by the head of IT before installation can complete!

QUOTE:
If you give up freedom for security you deserve neither - Thomas Jefferson -

SENSIBLE RESPONSE:
Fedora caved in to a knee-jerk reaction. The compromise should of been allowing admin's to white-list a subset of the signed packages that they want to allow all users unrestricted access to. The year of unnecessary security is upon us.

Re:Outrageous (0)

Anonymous Coward | more than 4 years ago | (#30171338)

SENSIBLE RESPONSE:
Fedora caved in to a knee-jerk reaction. The compromise should of been allowing admin's to white-list a subset of the signed packages that they want to allow all users unrestricted access to. The year of unnecessary security is upon us.

Wrong approach (and a stupid one at that).

Admins should be able to white list their users and grant trusted users the ability to install packages from a trusted source.

Oh wait, they already can. It's called sudo...

Re:Outrageous (1)

AdamWill (604569) | more than 4 years ago | (#30172368)

"The compromise should of been allowing admin's to white-list a subset of the signed packages that they want to allow all users unrestricted access to."

if the admin's going to go to all the trouble of whitelisting a subset of signed packages, why not just...install them? It's not like disk space is expensive. Also, I don't know a lot of admins who would welcome the prospect of trying to evaluate a list of around 10,000 packages as a great way to spend their weekend...

To quote Richard Hughes: (4, Informative)

Anonymous Coward | more than 4 years ago | (#30170826)

To quote Richard Hughes, the developer responsible for the braindeadness in the first place, and repeatedly trying to brag his competency of being a dickhead in the bugzilla(https://bugzilla.redhat.com/show_bug.cgi?id=534047 [redhat.com] ).:

Every time somebody writes "Linux is about choice" something inside of me dies. Just because something can be done, doesn’t mean it should be done.

Source: http://blogs.gnome.org/hughsie/2009/09/23/linux-is-about-choice/ [gnome.org]

It seems that he interpreted his own words as "Just because you can do something, doesn’t mean you should do it. But for me, I can fucking make whatever 'choice' and screw everybody else. Bwahahaha!"

And his recent rants:

And so, long story short, we decided to revert the change for F12.

Part of being an open source maintainer (and also my job at Red Hat) is to ignore trolls, but some of the messages I was getting yesterday were just personal attacks and abuse. That’s not cricket at all.

(Source: http://blogs.gnome.org/hughsie/2009/11/20/the-fedora-12-installing-saga/ [gnome.org] )

But he was the one who was being a troll first. Quotes from the bugzilla:

  • "It's not insecure. We've had the mechanism checked. The default policy may not be to your taste, but this is the "desktop" spin, not the "server" spin. " (btw, the two "spins" don't actually exist. --ed)
  • "There's nothing to discuss here."
  • "You either trust the Fedora repos or you don't."
  • "I don't particularly care how UNIX has always worked."
  • "You missed the "in my opinion" line in your reply."
  • "There are other, *easier*, ways of rooting the system. "

Now, I'm wondering how on earth did someone got a job for being a devtroll. Red Hat pays him to develop, but trolling the bugzilla? I don't remember anyone "attacking him personally" on the bugzilla. I wasn't following the mailing lists though.

And he now seemed hurt because the users actually bothered to donate their own time correcting his mistake.

Grow up.

Re:To quote Richard Hughes: (0)

Anonymous Coward | more than 4 years ago | (#30170990)

By the way, I'm the same AC posted the parent. I'm a long time Fedora user and I'm posting from a Fedora machine right now. I've always enjoyed the distro and used it exclusively. Because I posted as AC (for obvious reasons ;) some of you may mistake me for some random Ubuntu/Apple/MS/whatever fanboy/shill/whatever. I'm not. I'm just a Fedora user that got hurt by a devtroll wearing a red hat. I know that some rants on the bugzilla hardly tells anything about a man in general, and one man hardly tells anything about the Red Hat team in general, either. However, as professionals ("being paid to ignore trolls", paraphrasing his own words), he should have done much better!

We can tolerant problematic software. We know the technical stuff can be fixed in time and we try to help by occasionally writing bug reports and patches and submitting them to the bugzilla. But some response from the devs are just outrageous. We want updates, not flames!

Controversial controversy (1)

Fdisk81 (833349) | more than 4 years ago | (#30170922)

Do /. writers get paid by "controversy"?

Re:Controversial controversy (1)

u38cg (607297) | more than 4 years ago | (#30171076)

No, but they are paid per ad click, which is directly correlated with page views. How do you increase page views? Get people to comment. How do you get them to comment? Post "OMG abortion is teh wrong" type stories and sit back and enjoy the ensuing shit-storm as your users compete to view as many ads as possible^W^W^W^W^W^W discuss civilly the issues raised by the fine post.

Re:Controversial controversy (1)

AdamWill (604569) | more than 4 years ago | (#30172412)

Do /. writers get paid by "controversy"?

I submitted the initial story, but they edited it a bit a before publication. I'm _sure_ it didn't have three 'controvers*' in it, but I can't prove it to you, I didn't keep a copy of my submission. It _was_ pretty late last night. Usually I'd shoot myself in the head before writing something that inelegant. :)

Placeholder post for obscure and obtuse comments.. (0)

Anonymous Coward | more than 4 years ago | (#30170938)

...on a topic that nobody outside of the Linux "community" will care about. Please use a minimum of 1000 words to: 1) Nitpick any or all talking points discussed in TFA to the nth degree. 2) Illustrate your Linux expertise by telling us how it is better than other OS's by providing an example of how you took a task that took 2 hours to do in Windows down to just 20 minutes in Linux.

And the announcement got it wrong (2, Informative)

Antique Geekmeister (740220) | more than 4 years ago | (#30171008)

Notice that the announcement said:

> The update will require local console users to enter the root password to install new software
packages.

This is, of course, wrong. Such local installations are normally done with "sudo", which does not require root passwords.

This is the sort of linguistic sloppiness that lead to the shrieking by users. While such inconsistent behavior for the console versus logged in SSH users has no reasonable excuse and shouldn't have happened, the danger was much less than the early explanations lead reasonable people like me to believe, because many of the discussions left out the "this only works from the console" part. And given that the new Fedora release is taking a bit of time to download, we hadn't had the chance to try this ourselves.

Re:And the announcement got it wrong (1)

pembo13 (770295) | more than 4 years ago | (#30171862)

> This is, of course, wrong. Such local installations are normally done with "sudo", which does not require root passwords.

Obviously wrong? How are they going to use sudo if it isn't configured by default. This is Fedora not Ubuntu

A sensible compromise (3, Insightful)

Lemming Mark (849014) | more than 4 years ago | (#30171028)

The policy of allowing certain users to install software, within certain limits, is not crazy. It gives you:
* don't have users typing in the root password all the time
* if you need a codec or viewer plugin, the system can pop up a "Getting a viewer for you" window, rather than a "Can't view this, please install foo, put root password here"
* this is made possible because Linux distros have their own "app store" of approved software, which comes *from the distro* so you know where to get it and you know it's relatively unlikely to be malware. Windows and MacOS can't do this.

The limits included only giving these privileges to the console user, who probably has physical access and can root the machine anyhow, which is also sensible. But it also gives malware the local user might end up running (e.g. due to a Firefox compromise) the ability to install software. That's not necessarily too bad unless it's, for instance, installing vulnerable setuid-root software. So this needs to be thought about carefully before enabling on an individual machine, unless the distro has thought *even harder* about it so you don't have to. It doesn't really seem like the Fedora guys thought about it hard enough, even though it could be a good policy for the future if done right. And I don't think anybody is happy about such a major change in behaviour happening without it being announced and debated very publically.

I hope to see this feature reappearing in a future Fedora release - it's a good feature if they do it right. But they should be *even more* careful about what they permit and they shouldn't make dramatic behaviour changes occurring by default without heavy debate (and if you upgrade from an old version, rather than clean install, it should certainly say "This is a behaviour change, do you want it?" - probably defaulting to no.

Re:A sensible compromise (2, Informative)

blueg3 (192743) | more than 4 years ago | (#30172142)

With sudo, they don't need to type the root password, they need to type their own password.

Of course, you're still able to make the system behave so that users can install software without typing in their password -- it's just not the default now.

It would be nice, though, for package managers to support user installation (to the user's home directory).

Re:A sensible compromise (1)

Lemming Mark (849014) | more than 4 years ago | (#30172660)

Yes, though I don't think Fedora configures sudo access for users by default unless things have changed? But even if I were right about that, it could at least be set up by the administrator in order to avoid giving out the root password, which is probably still a good thing (though if sudo is configured to allow a user to run any command with it then I'm not sure that protecting root's password is that beneficial?).

The minimum thing I'd want to see *by default* is probably that a user has to type in *a* password, or even just click a UAC-style "yes, really do this privileged thing" through an interface that can't be intercepted by malware. Being able to silently install software would be really useful but only if the system's owner / administrator knows they've allowed for it. Unless, possibly, the packages that a user could install without verification were limited in certain ways (e.g. no setuid apps, can't use more than a certain disk quota)

Very much agreed that package managers really ought to support (by default IMO!) the ability to install to a user's homedir, whether or not that user has the ability to perform a system-wide install. I'm fed up of having to install stuff from source (without dependency management) just because I only want something in ~/.

Re:A sensible compromise (1)

AdamWill (604569) | more than 4 years ago | (#30172880)

Very much agreed that package managers really ought to support (by default IMO!) the ability to install to a user's homedir, whether or not that user has the ability to perform a system-wide install. I'm fed up of having to install stuff from source (without dependency management) just because I only want something in ~/.

High-level package managers generally don't expose that functionality because many packages aren't really built to expect it. In theory packages should be perfectly relocatable, but in practice most maintainers never test installing them anywhere but / , and they tend to do things based on the assumption they'll be installed to / and by a process with root privileges (for instance, updating certain databases in %post scripts wouldn't make much sense for a package being installed as a user). If you want to dice with death, though :), you can do it via rpm. 'rpm --root ~/some_directory -Uvh (packages)' should do the trick. You can also do it with yum - 'yum --installroot=~/somedirectory'. I haven't tried this, so I'm not sure what gotchas are involved, but the concept is there.

Re:A sensible compromise (0)

Anonymous Coward | more than 4 years ago | (#30172384)

Role Based Access Control anyone?

Tempest in a teapot (1)

caseih (160668) | more than 4 years ago | (#30171360)

How many Fedora installations actually have "users" and "admins?" The line that you don't want your users installing software just doesn't hold any water. Honestly if you have an "admin" and "users" you'll be wanting to harden the install anyway, and more than likely you will not want to use Fedora. Instead you'd do CentOS 5 or Ubuntu LTS. Most installs of Fedora are on single-user, home systems. Even in a family situation, a parent will likely want to enable parental controls anyway, so creating a limited account for the kids and using policykit to lock down what they can run (no terminal, etc), is one would do anyway. So bringing up security in the context of "users" is really a red herring here.

Even more ironically, most of the comments seem to indicate that sudo is a recommended solution! Are you kidding? How is that any better for admins and users? If a user wants to do something that needs more privileges, you grant him carte blanche root access? Even on OS X the access controls are this coarse. If the user is "administrative" he has full root access. The Fedora default made a lot of sense for home users but could easily be changed for other environments, though Fedora just doesn't belong in most enterprises.

What Fedora probably needs to do (maybe they have) is introduce templates for use when creating users. So you can easily create admin users, restricted users, etc. Slashdot users seem to have no complaint about the fact that you absolutely do *not* need root on OS X to install software. And even worse you can install software that's not cryptographically signed!

Re:Tempest in a teapot (1)

Tim C (15259) | more than 4 years ago | (#30171686)

Even more ironically, most of the comments seem to indicate that sudo is a recommended solution! Are you kidding? ... If a user wants to do something that needs more privileges, you grant him carte blanche root access?

That's not what sudo does, necessarily. There is a file that can be used to list the commands that a given user/group can run using sudo. If the command you're running isn't in that list (including the arguments you're supplying) then you don't get permission to run it.

It's common to allow people to sudo anything they want, but that is by no means the only option.

Re:Tempest in a teapot (1)

goarilla (908067) | more than 4 years ago | (#30172430)

not only that sudo can be configured to run commands as another user instead of root, it
can also be configured to disable shell escapes so :! /bin/sh doesn't work in vim

only temporary (0)

Anonymous Coward | more than 4 years ago | (#30171396)

It looks like they plan on changing it back for upcoming releases. Tehehehe! Get out your flame throwers!

The idea was that the change in PolicyKit would be accompanied by a
default set of roles, and a nice user interface for assigning users to
roles. Unfortunately, with the constraints of time, it became clear that
this all (and especially the GUI) wasn't going to be there for Fedora
12. So, PackageKit needed a fixed policy for all users. For each action
(install signed packages, install unsigned packages, remove packages,
etc.), it needed to allow, deny, or ask for the root password.

and

In upcoming Fedora releases, we expect to finish both the default set of
policy roles and the user interface components to provide the full
experience that was originally planned.

So redhat still plans on making this change. They are just waiting till they implement the GUI to easily change a user's role.

Re:only temporary (1)

AdamWill (604569) | more than 4 years ago | (#30172550)

So redhat still plans on making this change. They are just waiting till they implement the GUI to easily change a user's role.

Well, um, then it's not going to be the *same* change, is it? The point is that you'll be able to choose what kind of role a new user account has, and hence what actions it'll be able to do. A regular, non-admin user account won't be able to install software this way.

It is still a good idea for certain users (0)

Anonymous Coward | more than 4 years ago | (#30171574)

It is still a good idea for certain users to install packages.
Perhap a trusted group.

If only root can do it, then everyone is using sudo, and you system is less secure.

but.. (0)

Anonymous Coward | more than 4 years ago | (#30171810)

i'd be happy if they fixed the checksum file which incorrectly states the sha256 hashes are sha1.

Re:but.. (1)

AdamWill (604569) | more than 4 years ago | (#30172704)

i'd be happy if they fixed the checksum file which incorrectly states the sha256 hashes are sha1.

It doesn't. It states that the signature on the CHECKSUM file is SHA-1, which it is. The file is signed with an SHA-1 signature, the checksums themselves are SHA-256. This is admittedly somewhat confusing, and will be changed to be less so in Fedora 13. But it's not incorrect.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?