Orwell’s 1984 From Freedesktop,org?

Home » CentOS » Orwell’s 1984 From Freedesktop,org?
CentOS 22 Comments

What is going-on ? It really looks Windozed ! Looking at it makes me feel ill.

22 thoughts on - Orwell’s 1984 From Freedesktop,org?

  • Seriously??
    If, as most linux folk do, you run your desktop as a normal user (i.e. NOT root) and then you try to do some system type changing, then there are two options –
    1. tell the user to go away
    2. ask for suitable credentials The authenticate dialog box is offering to complete the task as long the password for root is supplied – what on earth is wrong with that?
    On the command line you just get a cryptic not allowed, insufficient rights etc. type message, with GUI the developer is interpreting this and offering to escalate privileges if you can prove you are allowed.

    Most of the applications under the system/administration tab of the gnome desktop offer this kind of dialog. Sorry I don’t see the reason for the paranoia.

  • Surely Linux users change to Root to do system work, rather than attempt to make Root changes in the middle of doing ordinary GUI tasks whilst logged-in as a normal user ?

  • Just out of curiosity: how do you guys look at it? This asks me for password… In general it is good idea to place something into open URL

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Originally, packagekit, which is a GUI package manager, wanted to allow all users to install anything without a password. When a bug report was filed, the developer mentioned that they didn’t care how Unix had done things in the past. This made the front page of slashdot, to almost universal derision, and RH changed it. In Fedora, I believe it still allows any user to update an installed signed package without asking for authentication.

    They tried to do that in RH as well, but a bug report was filed, and it was changed.

    In my less than humble opinion, this is how it should be. A non-privileged user should not be allowed to make changes to the system.

  • Everyone’s entitled to his own opinion, so I respect your right to that view.

    First, as to paranoia, how much $ is spent because of justified paranoia in this world? ISTM that paranoia is justified by that alone. Second, I
    spent too many years working with “those who know best” developing software and systems when there was rigorous methodology to have any unjustified faith in those who now work in a “throw it against the user wall and see what sticks or gets reported as buggy” methodology.

    I don’t want this stupid thing popping up every time I switch from my normal active user logons to my “dead” one (used to get around the unaddressed bug I filed over a month ago about switching run levels causing crashes and running multiple users as I’d been doing for … over a decade(?) on CentOS).

    Even windows doesn’t make me repeatedly click cancel if I’m not ready to update (I have one Windows box for one application I do and my wife has a couple) – it raise a little … “flag” saying updates are available (I
    have “check with me” set rather than allowing auto updates).

    Yesterday on this 6.6 box I had to click cancel many times – most on one switch of users as apparently they queue up.

    AFAIK, tools are provided (sudo, “su -“, …) for non-root users to invoke and accomplish these functions on *their* schedule, rather than that set by some anonymous “one who knows better”.

    MHO, Bill

  • I run a small consulting service and work with both individuals and (very) small businesses. The objective of my consulting business is to help average people move to Linux when they decide that they have had enough of the M$ money wheel and endless malware infections.

    Not one individual who belongs to that class of users cares how Uniix/Linux works, how it does updates or how to install new stuff. They *DON’T WANT* to know all that stuff. They want only one thing; to use the computer as a tool to perform needed personal or business tasks.

    My wife is my most frequent client and she in every way reflects the attitude of every customer – except for two – that I have. “Don’t teach me how the computer works. I don’t care. Just make it work for me,” is the common refrain. If there is a problem, she calls me; if she wants new software installed, she calls me;
    if updates are required, she does not want to see any pop-up messages, she just wants her system to be updated automatically when needed.

    In most cases I go onsite to install new software or do updates. HOWEVER!!!
    There are times when I need to talk a customer through doing something that they would never, ever do if there were any other choice. They understand when that happens and together we can always do it in far less time than it would take for me to travel there and back.

    But I *NEVER* want them to go mucking about on their own – EVER! They have no idea what they are doing and should not be doing any type of admin stuff – and that is really how they want it. They should be password protected from everything administrative or they will cause me much more work and cost themselves a great deal of money as I try to fix the predicament that they have gotten themselves into. For example, I cannot tell you how many times I get a call from users who have purchased a new printer and tried to install the software from the accompanying CD. AARRRGGHHH!! I tell them to just plug it in and it should work without installing any software, and for those who have purchased Lexmark printers, I tell them to take it back and get something supported. I am so glad they cannot try to force that software onto the Linux box.

    I disable and remove PackageKit to prevent that kind of stuff.

    As for those other two customers, they don’t really care much anyway. They have the knowledge but not the time to perform the tasks they hire me to do. They really don’t want me to change much as they have it working the way they want and like it. That includes updates – or not doing updates – and everything else.

    For those historically ignorant developers, I say that they had *BETTER* care how it has always been done! It is that history, that philosophical difference from other operating systems that has made Linux as popular as it is today. Change is good, but the philosophy of Linux is important to ensure that the power, flexibility, security, reliability, and quality of Linux do not suffer.

    See my article: https://opensource.com/business/14/12/linux-philosophy and I
    have another article as follow-up that should appear there soon.

    So, Scott, that is a very long-winded and rantful way of saying that I agree with you. ;-)

  • My current plan too once I determine it won’t break my boxes.

    +1
    I started working on UNIX in 1978 after a long time on “big iron”
    systems and my early words were “This is the way we should’ve been doing it all along”. Pretty soon I introduced the first real UNIX on PCs into our development group (circa, strangely enough, 1984) that tied into Dec equipment emulating 3270(?) to the mainframe where, at the time, our source, development processes and user base (distributed across the nation) resided. We gained a lot by doing initial development, compiling and testing on the PCs and then final test and installation only, along with distribution, on the mainframes.

    Keep up the battle!

    Bill

  • I logon with my normal user id and run a development desktop. Then I
    open terminal sessions and su -l into root as I need to. However, if you need to use a GUI tool with root privileges running from a standard user desktop then you have to provide the root password. This has been the case for as long as I can recall whether it is package updating or running virt-manager.

    However, this thread from 2009 might provide some guidance on getting around that. I have not followed it so it might be a dead end. But, the lead is free so ‘youse pays yer monies and yer takes yer chances’.

    https://www.redhat.com/archives/fedora-desktop-list/2009-October/msg00053.html

  • I have not encountered this behaviour in any CentOS-5 or 6
    installation. All I ever get is a starburst icon in my top panel when there are unapplied updates. Are you telling us that when you switch users (how exactly are you doing that?) that this PackageKit dialogue window displays without any further action on your part?

  • I realize it now, after you mentioned it. I fill so sheepish ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • I would second that (or third, or hundredth…). I hate Adobe for putting SUID-ed “plugin-config”, thus enabling regular user write where only root can. This crap triggers my system integrity alarms. I always have to remove SUID bit then set immutable bit so the crap doesn’t resurrect with their update. In the same list of bad guys comes google with its chrome browser, that drops in daily cron job. Which I have to remove and put placeholder (with immutable bit set), so it doesn’t resurrect… Other people have their too lists I bet.

    As a matter of fact I tend to not use GUI admin tools since long ago. Even on machines I sit in front of as a regular user. I prefer to grab root shell for that. This is, BTW why I prefer plain ASCII text human readable config files, and hate the move towards GUI only based administration. One single case is different for me: I do prefer 3ware web RAID admin interface anything else (it more transparently prevents me from making fatal blunders – probably just me).

    And yes, disabling root user and having sudo instead is on my evil list too: yet another SUID-ed binary, and potential holes due to some garbage in config file… BTW, su (with the same password for root as regular user has), and attempt to use sudo are the fist two things bad guys try when they log in with stolen password of regular user (after a compromise of machine elsewhere).

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Bring back Xconfigurator!

    No, not just you. tw_cli is needlessly confusing in its command structure.

    Compare the operation of the ZFS and btrfs command line tools, to see how it should have been done.

    Given how old and battle tested sudo is, I think we can trust it.

    My only remaining unease comes from the fact that the sudo binary is about 4x the size of su.

    Still, I

  • That is exactly what I meant to say to everybody (if you read the rest of what I wrote you will realize that I don’t make blunders of this magnitude!). Thanks for spelling it out in more plain Engish language than I managed to ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • And after re-reading what you have said I see that I didn’t state clearly enough originally what bad guys do. Of course, your advises stand too. However:

    when some machine is compromised on the network, then:

    1. key pairs are getting stoles (so authorized key authentication to other machines with credentials of a user gets possible wherever this user set it)

    2. keystroke logger is installed and malicious SSH client binary is installed. Thus triplets: hostname, username, password are getting collected for all remote machines users connect from compromised machine.

    3. After some time (usually 1-2 Months – my observation) information collected in 1-2 is getting used for the first time. Thus, bad guy will connect to the machine you administer with credentials of one of your users. First thing that is being tried is lame admin job: su (with the same password as the one that was stolen for that user account) and sudo
    (in case you gave that user sudo privilege). (and only after that go attempts of local elevation of privileges using LKM, bugs in SUID-ed binaries, ….)

    That is why admins usually exercise paranoia when they use their almighty privileges. Have you ever typeed root password in a shell of another user to do something for him using root privileges? I know one senior admin (I
    was junior admin working with him then) who was caught by smart students because of doing that, so they got root on the machine. But I think this may be long talk deserving quite different thread. If someone wise (which I’m not) will start it, I’ll see if I can add something too (which I
    actually doubt knowing how many awfully knowledgeable people are on this list ;-)

    And, BTW, that is why I run multi-user machines under assumption that bad guys are already in. Whatever they do, they shouldn’t be able to elevate privileges, or do local user DOS. But, of course, all of us have seen them already in, and trying…

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Just you wait till you get to the MegaRAID command line! It makes tw_cli seem like echo in comparison.

    I found the 3ware web interface too clunky for my purposes, so I forced myself to learn tw_cli. Once I used it regularly I found it to be mostly usable. I’ve yet to do this with megacli or storcli, and those are so much more complicated than tw_cli, so I haven’t learned them very well yet.

    But (getting back a little to the original topic) getting to the 3ware web interface should not require root privileges on the client, since it’s just the browser connecting to the 3ware http(s) listener. The OP
    seemed to be ranting about a prompt for an administrative password from the desktop environment.

    –keith

  • Yes, this is as bad as it can be. Users in “enterprise” environment shouldn’t be asked admin (root) password. And even prompted that these or those things (“updates”) are available. Don’t they have sysadmin, or he sleeps on his job? No, he is just overworked weeding out all this crap from systems he supports ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Actually, my rant was much more about it interrupting me, without being asked, to do some updates that I didn’t yet request *and* being persistent about it over time in *my* (not Freedesktop.org’s) work space.

    I already get notified of available updates, *without* offensive or persistent intrusion, by the updates available icon on the panel on my Gnome desktop. It was suitable IMO.

    Before 6.6 broke the runlevel/X multiple session functionality (going from 3 to 5 results in instability when multiple X sessions are to be used), causing crashes (another great result from those who “know better” as they screwed around with “init” and the inittab processing?), I would then log the users off, drop to run level 3, do an rsync backup of home, boot and root, do yum updates (sometimes selectively, as in doing glibc* and kernel stuff first and then re-booting to do the rest)
    and then return to the normally scheduled programming.

    I like it that way – it’s secure, keeps me aware of what is going on on my machines w/o having to rummage through logs, mail, or worse.

    As a concession to the now broken runlevel/X multiple session processing, I remain in run level 5 and do the backups etc. Not the way I would prefer.

    And now since I filed a bug and reported the crash and provided narrative and files and have seen 0 movement on the bug, I wonder why I
    wasted my time reporting it. If I was missing something I would hope at least a reply requesting more info or whatever would be forthcoming.

    Maybe Rodney Dangeruser “Don’t get no respect”? ;) Well, at least
    “upstream”.

    Bill

  • Perhaps if you’d specified that in your original post there would have been a lot less confusion about what you were upset about.

    Exactly where did you report this bug? If it was to RH, and you’re not a RH customer, you shouldn’t be surprised if they ignored the “bug”, since they probably consider it a configuration option, not a bug.

    –keith

  • That is my intent. But until one encounters the new behavior and realizes that the facility behaves that way (and it never did in the past – I guess I didn’t have it enabled or it wasn’t part of the standard install?), it is aggravating. I only had the little star in the panel before, and it’s still there. That’s good enough for me.

    Being a non-admin type, I’ve tried to keep all the underlying stuff pretty much “stock” and I have no idea how deep I can go without compromising what I value – the reliable, stable behavior that has fit my M.O. for so many years prior to 6.6. E.g. I now boot into run level 5
    since the transition from 3->5->3->5 … is broken now. I could fix it it I suppose if I was willing to dedicate the hours and effort to it instead of doing what I need and prefer to do now.

    But avoiding that sort of onus is why I chose CentOS.

    I’m one of those “you broke you fix it” believers that tries to avoid placing myself in that position now that the computers are just a tool for me.

    Bill

LEAVE A COMMENT