Sudo su

It came to me that whilst it's safer and easier for me to use sudo for accessing things as root temporarily, someon wouldn't bother trying to get into my user, as root login from shell is disabled, only to try and guess another, more complicated password for su, when they could just do sudo su. So I blacklisted su and shell from my sudo. Having said that, other than those few things blacklisted, I have the ALL setting in visudo for me, mainly for conveinience because I am the only user and admin of this laptop. The beginners guide (certainly when I installed Arch) said to use the ALL option, but now I'm figuring, even with su blacklisted, I would be better of doing a whitelist of thing I often need as root, like pacman and emacs etc. I was going to put something about this blacklisting business in the wiki but after ponding su, and user, owner, and group permissions, I'm beginning to doubt the usefulness of sudo, especially for people who have the setup I do, i.e. it's their laptop, and no-one else uses it.
Just wondered what the opionion of fellows more learned in the security aspects of Linux than myself is.
Cheers,
Ben.

I'm in an administrator account. I have MAMP (http://mamp.info). It says this is to add these programs to the system path.
I'm using this book: http://www.sitepoint.com/books/phpmysql4/
Here's what happens when I try "sudo su": (it looks like the password area is blank, but I did type my password. It must just show up blank so you can't see the password)
Here's what happens when I try "sudo" and then the code provided by the book.
I may just forget about this and use my own web server at http://www.danielshamburger.com/ (already has PHP and MySQL and all that stuff) and make a /dev password protected directory.
Thanks!

Similar Messages

  • Unable to install Matlab in sudo mode

    I am trying to install 64-bit version of Matlab in my ArchLinux, running KDE.
    The installer was able to start when I typed
    /media/iso/instal
    (install being the install sh script).
    However, it wasn't able to create folders due to permission limits.
    So, I decided to run it as a root, I type
    sudo /media/iso/install
    and it gave me bunch of errors and existed to the prompt again.
    Here is just part of that error message
    Preparing installation files ...
    Installing ...
    No protocol specified
    No protocol specified
    Exception in thread "main" com.google.inject.ProvisionException: Guice provision errors:
    1) Error injecting constructor, java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment
    at com.mathworks.wizard.ui.laf.UIDefaultsTableImpl.<init>(UIDefaultsTableImpl.java:17)
    while locating com.mathworks.wizard.ui.laf.UIDefaultsTableImpl
    while locating com.mathworks.wizard.ui.laf.UIDefaultsTable
    at com.mathworks.wizard.ui.laf.LookAndFeelModule.provideUIProperties(LookAndFeelModule.java:41)
    while locating com.mathworks.wizard.ui.laf.UIProperties
    for parameter 4 at com.mathworks.wizard.ui.WizardUIImpl.<init>(WizardUIImpl.java:75)
    while locating com.mathworks.wizard.ui.WizardUIImpl
    while locating com.mathworks.wizard.ui.WizardUI annotated with @com.google.inject.name.Named(value=BaseWizardUI)
    at com.mathworks.wizard.ui.UIModule.provideWizardUI(UIModule.java:36)
    while locating com.mathworks.wizard.ui.WizardUI
    for parameter 0 at com.mathworks.wizard.ExceptionHandlerImpl.<init>(ExceptionHandlerImpl.java:23)
    while locating com.mathworks.wizard.ExceptionHandlerImpl
    while locating com.mathworks.wizard.ExceptionHandler
    Caused by: java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment
    Last edited by kdar (2010-10-24 13:31:09)

    ngoonee wrote:
    When you're root some env variables aren't propagated, so probably your java env variables are among those.
    I'd suggest installing Matlab as user, that's what I do with mine. Just create a folder anywhere (let's say /opt/Matlab) and chmod -R youruser:yourgroup on that folder, and you're good to go.
    Thanks that worked, but I just realized I have not enough space on my root partition.
    I guess I will just install it in my home folder somewhere.

  • Applescript for running sudo commands in terminal

    I'm a newbie when it comes to Applescript and was wondering if someone could help with a basic request. I need to write a small script to do the following:
    1. Launch terminal
    2. Run the 'Sudo -s' command
    3. Enter the administrator password (in plain text)
    and then
    4. run some sudo commands like "sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add administrator"
    I actually WANT the administrator password to be in the script in plain text even though I understand the security risks (I will literally be the only person to ever see the script). I've trawled forums all over but can't seem to find what I am looking for and cannot get it working by patching together the various commands I have found. Thanks in advance for any help you can give!
    Sean

    I've included two examples.  The preferred way & the hacker way.
    with administrator
    It is easier to diagnose problems with debug information. I suggest adding log statements to your script to see what is going on.  Here is an example.
        Author: rccharles
        For testing, run in the Script Editor.
          1) Click on the Event Log tab to see the output from the log statement
          2) Click on Run
        For running shell commands see:
        http://developer.apple.com/mac/library/technotes/tn2002/tn2065.html
    on run
        -- Write a message into the event log.
        log "  --- Starting on " & ((current date) as string) & " --- "
        --  debug lines
        set unixDesktopPath to POSIX path of "/System/Library/User Template/"
        log "unixDesktopPath = " & unixDesktopPath
        set quotedUnixDesktopPath to quoted form of unixDesktopPath
        log "quoted form is " & quotedUnixDesktopPath
        try
            set fromUnix to do shell script "sudo ls -l  " & quotedUnixDesktopPath with administrator privileges
            display dialog "ls -l of " & quotedUnixDesktopPath & return & fromUnix
        on error errMsg
            log "ls -l error..." & errMsg
        end try
    end run
    This version has an inline password.
    Notice the echo 'password' |
    The single quotes are no accident.
    It is easier to diagnose problems with debug information. I suggest adding log statements to your script to see what is going on.  Here is an example.
        Author: rccharles
        For testing, run in the Script Editor.
          1) Click on the Event Log tab to see the output from the log statement
          2) Click on Run
        For running shell commands see:
        http://developer.apple.com/mac/library/technotes/tn2002/tn2065.html
    on run
        -- Write a message into the event log.
        log "  --- Starting on " & ((current date) as string) & " --- "
        --  debug lines
        set unixDesktopPath to POSIX path of "/System/Library/User Template/"
        log "unixDesktopPath = " & unixDesktopPath
        set quotedUnixDesktopPath to quoted form of unixDesktopPath
        log "quoted form is " & quotedUnixDesktopPath
        try
            set fromUnix to do shell script "echo 'password' | sudo ls -l  " & quotedUnixDesktopPath
            display dialog "ls -l of " & quotedUnixDesktopPath & return & fromUnix
        on error errMsg
            log "ls -l error..." & errMsg
        end try
    end run

  • Application Sudo listed in Activity Monitor - Is this a default app that should be running?

    First Question:        Do other MBP users have an application Sudo listed in Activity Monitor from start up of their mac or with typical use?
    Second Question:   If you have Sudo process listed in your Activity Monitor, do you also use an Huawei USB wireless modem?
    Third Question:       For those experienced in relevant coding domains and given the more technical details below - your thoughts?
    (Technical)
    Using MBP Retina, mid 2012, OSX 10.8.4
    I understand sudo is a unix root level access command. 
    I have used Terminal and become familiar with some basic unix commands, including using the sudo command in very limited single action command circumstances.  I have not used Terminal for many weeks, and the sudo command probably twice several months ago. 
    Sudo showing in Activity Monitor as an active process is to my understanding an entirely different situation to it being used in Terminal.  It appears the sudo process is being activated by some other application or process not of my direct use or actions.
    I remain a little concerned about this in view of the purchase of this particular MBP. It has a story to it. I was told this MBP was available as new on discount as it had been purchased by a man for his wife, the wife then left him, and subsequently he returned it unused to the store.   I was aware that there was a slim risk the laptop had been used for some other activities, and returned so any come back comes back to the new owner.
    I noted later with use that the MBP lower keys were sticky as if something has been spilt on them, so I do wonder if the laptop was previously used, then wiped, in which case the story presented to the retailer is likely not true and a more concerning scenario becomes possible.  
    All the same, I felt a clean install should remove any risk.  The MBP arrived in standard ready to set up and go mode, so OS loaded but no activation.  So it seemed a clean install to me.   I did not wipe the HD and do a fresh OS install from scratch. A decision I now regret.
    Some months after using this new MBP, my concerns were raised when I had one day of inexplicable internet usage on a wireless internet connection.  Not only did the level of data upload and data load, about 4 GB out of 20 GB for the month not make sense with actual usage, but also the MBP system logs did not tally with the internet providers accounting of usage on that day.  There have been two or three other anomalies in usage since.  The internet service provider reimbursed me on my evidence of OSX system logs.  Not sure if the service provider has people joy riding other users accounts or something suss this end was going on. Never resolved. The ISP was not exactly forthcoming, and I had to press hard to get some collaboration on resolve the anomaly of unexplained data usage.
    On the less suspicious side, the existence of this sudo program tracked down as in part coming from the install software from a Huawei modem provided by my internet provider.  However, while widely used and therefore likely not a security risk, I still feel need for some better explanation and resolution of the persistent sudo process. 
    I have  inquired to Apple Support about this sudo app running, and it apparently was not seen as an issue of concern by the front line support staff.  I took up some further concerns with them but checks indicate no issues of concern with the MBP from their assessment. I trusted that as fairly likely a definitive view, and so left the questions and anomalies as unexplained but harmless. 
    It is now several months later and I still find the existence of sudo as a running application or process in Activity Monitor troubling, and decided to try and resolve once again how typical and for what reason it is active on my MBP. Which brings us to this post.
    I have again spent a few hours searching on Google and Apple Support Forums.   All search results I find relate to the use of sudo as a unix command in Terminal to resolve a problem.  I can not find any indication of sudo as an app being open routinely in Activity Monitor with or without Terminal being opened or used.
    The only way I can think of to resolve if this is unusal or not is to get on this forum and ask the first two questions at the top of this post.
    More technical details follow.
    For some more technically minded the details may be of interest, hence below here I have added  details for further comment.   I am hoping some MBP users on this forum may also be coders, and hence have some idea of the internal mac coding environment. Enough to shed some light on this situation. 
    As mentioned, I think the sudo Activity Monitor may originate from the running of the Internet Providers USB Wireless Modem and software (Huawei E 169? modem).  The USB modem has the install software on it.  You install that software on your HD as an application. 
    On this USB Wireless Modem front I have done some checking.  
    Killing sudo in Activity Monitor does not stop an internet connection mid session. 
    When the USB modem is removed, the sudo process remains running and listed in Activity Monitor. 
    If I remove the Modem icon, unplug modem, close all apps, restart without the modem connected, the sudo process is still loaded and running in Activity Monitor.
    Months ago on a previous check if I deleted (uninstalled) the modem software, removed associated start up files installed by the modem installation, took out the USB Modem and did a restart, there was no return of the sudo process in Activity Monitor.  When the modem software was reinstalled or the start up files restored directly, the sudo process returns to Activity Monitor.  One of the software bits installed in start up files calls sudo (or so it appears having a peak in BBedit at the files.)
    This seems to fairly much establish the source of the sudo application. However it does not resolve why it needs to be open all the time, and if this is unique to this modem, my modem,  modems in general, or if permanent running sudo processes are fairly 'normal' in general.  Since sudo is a root level access process, I do feel a little concerned of the situation.   Let's say the sudo process is needed to initiate the modem under some justification.  Does the sudo process in remaining running permanently from there on, with or without the USB modem connected leave an open access way and vulnerability that can or is used later?   i do not know enough of the coding level architecture to form a view.   Still, seeing a permanent sudo process operating does niggle by sense of suspicion.    Hence, I continue to raise this issue and ask the questions I do.
    In Activity Monitor:
    sudo as a process when running is not very active.  
    Real Mem 8 KB, Virtual Mem 9.4 MB, Sent Msgs 75, Rcved Mesgs 26, Ports 25, Intel (64 bit).
    The sudo process:
    Using Sample Process in Activity Monitor:   sudo appears to be a running of the actual sudo command from within the unix command files.
    Path:            /usr/bin/sudo  (Master Library, not the one in the User files)
    Load Address:    (removed)
    Identifier:      sudo
    Version:         ??? (???)
    Code Type:       X86-64 (Native)
    Parent Process:  launchd [1]
    Call graph
    2nd line is 2656  start  (in libdyld.dylib) + 1  [(removed)]
    Binary Images:
    Includes reference to lots of .dylib files. eg libcache.dylib, libquarantine.dylib, libremovefile.dylib, libcompiler_rt.dylib, libcorecrypto.dylib
    The parent process is launchd[1]
    Process:         launchd [1]
    Path:            /sbin/launchd
    Load Address:    (removed)
    Identifier:      launchd
    Version:         ??? (???)
    Code Type:       X86-64 (Native)
    Parent Process:  ??? [Unknown]
    It seems all of the activity of launchd[1] is from the sudo process.
    Again reference to .dylib files as captured in call graph and Binary images.
    I hope the details are valued by someone with an interest to assist with resolving concerns.

    Thanks,
    I usually use the OS connection option. So as you suggest, connect without the ISP connection software.  Doing so does not by-pass the sudo command being active in Activity Monitor however. 
    On reading my post I see my failure to link the concerns of the laptop purchase with the sudo and modem. My thought here is of an intersection of known vulnerability with this widely used modem/software (via permanent sudo process activated) and that vulnerability then being known and utilised by another party(s).
    I am pursuing the issue in part with consideration to a broader possible issue of vulnerability.
    Thanks again for your thoughts and suggestions. Valued.

  • I am trying to use the sudo tmutil disable local on my macbook air but when it asks for my password, I cannot type it in- the letters simply do not appear on my screen-- any solutions??

    I am trying to free up space on my macbook air by stopping local backups. I type sudo tmutil disablelocal and it prompts me for my passsword. When I try to type in the password it wont type-- i.e the letters do not apear when I type them-- any suggestions??

    Hi there... 
    For security do not appear in code, but once you hit ENTER it has been passed in Terminal ...careful to write the code properly and kaps lock

  • I am trying to install oracle 11g xe on ubuntu aws instance when i execute sudo /etc/init.d/oracle-xe configure command iam getting this error: sudo: /etc/init.d/oracle-xe : command not found

    i am trying to install oracle 11g xe on ubuntu aws instance when i execute sudo /etc/init.d/oracle-xe configure command iam getting this error: sudo: /etc/init.d/oracle-xe : command not found.

    "command not found" means ... there is no such thing.
    Has the .rpm been installed?
    http://docs.oracle.com/cd/E17781_01/install.112/e18802/toc.htm#XEINL122

  • Su doesn't work anymore but sudo works

    Hi all,
    I normally use my standard user account but when I'm installing with macports I routinely "su" into root to do things.
    Today I went on my machine and noticed that "su" wouldn't work. Before anyone decides to tell me that I don't need to use "su", I realize that but I use it for my own purposes.
    From the system log I am seeing this each time "su" fails:
    su[1376]: pam_authenticate: Permission denied
    What is interesting is that doing a "sudo su" works, and I'm able to do all of my admin duties that way.
    I have a feeling something messed up my bash profile but not totally sure. Has anyone else run into this issue?

    Hi all,
    Thanks for the help on this issue.
    I'll clarify: I'm using this install as a server and this is why I have 2 admin accounts on it. The original account is my own; the one I created when I first installed OS X. I then enabled System Admin (root) so that is the other admin account. After installing MacPorts I have been running the system as a multi-user webserver. I occasionally log in as root to do maintenance and upgrades. I have found that it's easier to use the SysAdmin account in certain situations because of permissions issues and ease of installing upgrades.
    I'll often log in under my username and then su to root. Recently (yesterday) I noticed that "su" didn't work anymore when I used my normal username.
    There are sometimes that I will log onto the machine as System Admin and usually via the terminal (console) I can log in as any of the other accounts by doing
    su <username>
    this also doesn't work anymore. I get the error:
    shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
    I have two servers set up this way. One works the way it should, the other one has this problem. The only difference I can see is in roots bash profile but I'm not sure why they are different on each machine.
    Also when logged in as System Admin, I should be able to turn off "allow user to administer computer" on my regular account but it's grayed out. On the other similarly configured machine, under the same conditions, I can. I'm not sure why I can do it on one and not the other.
    I've tried turning off enable root via Directory Utility but that didn't fix the issue.

  • Sudo doesn't work anymore, not permitting me to enter password

    Since two days, sudo doesn't work for me anymore. When I do
    sudo any_command
    I get:
    Sorry, try again.
    Sorry, try again.
    Sorry, try again.
    sudo: 3 incorrect password attempts
    I updated my server two days ago, but I cannot say whether it's related to my problem.
    Here's the result of doing
    tail /var/log/sudolog
    as root (su works):
    Oct 13 12:35:33 : kalasusi : 3 incorrect password attempts ; TTY=pts/2 ; PWD=/etc; USER=root ; COMMAND=/bin/ls
    Here's the result of doing
    tail /var/log/auth.log
    as root (the last new lines after trying sudo again with my normal user):
    Oct 13 14:52:59 myserver sudo: pam_unix(sudo:auth): authentication failure; logname=kalasusi uid=0 euid=0 tty=/dev/pts/1 ruser=kalasusi rhost= user=kalasusi
    Oct 13 14:53:05 myserver sudo: kalasusi : 3 incorrect password attempts ; TTY=pts/1 ; PWD=/home/kalasusi ; USER=root ; COMMAND=/bin/ls
    For some background info, the sudo troubleshooting guide identifies such a problem (the third Q&A):
    Q) Sudo never gives me a chance to enter a password using PAM, it just
       says 'Sorry, try again.' three times and exits.
    A) You didn't setup PAM to work with sudo.  On Redhat Linux or Fedora
       Core this generally means installing sample.pam as /etc/pam.d/sudo.
       See the sample.pam file for hints on what to use for other Linux
       systems.
    The only problem is that I didn't change anything from the Arch stock configuration of /etc/pam.d/sudo, and it used to work. Here's the result of
    cat /etc/pam.d/sudo
    on my system:
    #%PAM-1.0
    auth required pam_unix.so
    auth required pam_nologin.so
    Something else that comes into my mind that might be connected with the problem is that at some point while doing maintenance on the server, I received the following error:
    Authentication token manipulation error.
    Unfortunately I don't remember in what context it was or whether the problem started afterwards. I believe though the problem is either that or the update, because those are the two extraordinary things that happened on the server since the problem started.
    Anyone have any ideas? Thanks in advance!
    Last edited by kalasusi (2010-10-13 23:20:14)

    [2010-10-11 22:08] Running 'pacman -Syu'
    [2010-10-11 22:08] synchronizing package lists
    [2010-10-11 22:10] starting full system upgrade
    [2010-10-11 22:12] Generating locales...
    [2010-10-11 22:12] en_US.UTF-8... done
    [2010-10-11 22:12] en_US.ISO-8859-1... done
    [2010-10-11 22:12] Generation complete.
    [2010-10-11 22:12] upgraded glibc (2.12.1-1 -> 2.12.1-2)
    [2010-10-11 22:12] upgraded binutils (2.20.1-3 -> 2.20.1-4)
    [2010-10-11 22:12] upgraded libmysqlclient (5.1.50-1 -> 5.1.51-1)
    [2010-10-11 22:12] upgraded logrotate (3.7.8-1 -> 3.7.9-1)
    [2010-10-11 22:12] upgraded mysql-clients (5.1.50-1 -> 5.1.51-1)
    [2010-10-11 22:13] upgraded mysql (5.1.50-1 -> 5.1.51-1)
    [2010-10-11 22:13] upgraded php (5.3.3-1 -> 5.3.3-2)
    [2010-10-11 22:13] upgraded php-cgi (5.3.3-1 -> 5.3.3-2)
    [2010-10-11 22:13] upgraded php-gd (5.3.3-1 -> 5.3.3-2)
    [2010-10-11 22:13] upgraded php-mcrypt (5.3.3-1 -> 5.3.3-2)
    [2010-10-11 14:19] Running 'pacman -S apache'
    [2010-10-11 14:21] installed apr (1.4.2-1)
    [2010-10-11 14:21] installed unixodbc (2.3.0-1)
    [2010-10-11 14:21] installed apr-util (1.3.10-1)
    [2010-10-11 14:21] installed apache (2.2.16-1)
    [2010-10-11 14:28] Running 'pacman -S php-apache'
    [2010-10-11 14:28] installed php-apache (5.3.3-2)
    [2010-10-12 19:46] Running 'pacman -Rns php-apache'
    [2010-10-12 19:48] removed php-apache (5.3.3-2)
    [2010-10-12 19:51] Running 'pacman -Rns apache'
    [2010-10-12 19:51] removed apache (2.2.16-1)
    [2010-10-12 19:51] removed apr-util (1.3.10-1)
    [2010-10-12 19:51] removed unixodbc (2.3.0-1)
    [2010-10-12 19:51] removed apr (1.4.2-1)
    [2010-10-12 19:52] Running 'pacman -S nginx'
    [2010-10-12 19:52] installed nginx (0.8.52-2)
    [2010-10-12 20:01] Running 'pacman -S php-fpm'
    [2010-10-12 20:01] installed libevent (1.4.14b-1)
    [2010-10-12 20:01] installed php-fpm (5.3.3-2)
    [2010-10-12 13:45] Running 'pacman -Rns nginx'
    [2010-10-12 13:45] removed nginx (0.8.52-2)
    [2010-10-12 13:46] Running 'pacman -Rns php-fpm'
    [2010-10-12 13:46] removed php-fpm (5.3.3-2)
    [2010-10-12 13:46] removed libevent (1.4.14b-1)
    As you can see, I installed (and removed) apache and nginx, as I was testing their performance. I don't think it's related to this issue, but I'm adding this here for the sake of completeness.
    Last edited by kalasusi (2010-10-13 23:26:13)

  • Damaging Terminal sudo session?

    I’m new to Mac (less than a year), and to administering my own computer. Trying to get things right and agreeable to me, for security and utility, is taking up much of my available time—as much as, or often more time than I spend USING my Mac.
    Recently, I tried to use a sudo command in Terminal for the first time, following advice published by Macworld for forcing updates to OS X’s new XProtect malware definitions, and I wonder whether I’ve done any damage by what I did, from knowing next to nothing about command-line protocols, how to exit Terminal properly, and so on. I have a spring 2011 MacBook Pro, running OS X 10.6.8 (it may have been running a prior update version when I got myself into that maybe-troublesome Terminal session some weeks ago).
    The command I ran, per the Macworld article, was “sudo /usr/libexec/XProtectUpdater,” which brought up this typical warning: “Improper use of the sudo command could lead to data loss or the deletion of important system files. Please double-check your typing when using sudo. Type ‘man sudo’ for more information. [Which I did, haplessly: I didn’t then know how to get further down that file than what was appearing in the window!] To proceed, enter your password, or type Ctrl-C to abort.” After my visit to man sudo and maybe then having to paste in the sudo command again, to run it I entered my admin password. As no characters were appearing in the Terminal window for the password, I thought nothing was happening; but I pressed the Enter key (or the appropriate button in the password pop-up, whichever was the case) anyway.
    When (eventually) I tried to close the Terminal window (without knowing at the time about using the exit command), I got this pop-up message: “Do you want to close this window? Closing this window will terminate the running processes: …” followed by a short list that included, I think, login, sudo, man, maybe bash. I chose to close the window anyway, and immediately worried that I may have done something I shouldn’t have.
    After running that updater command again on one or two other occasions since (though those times exiting Terminal through the exit-command route), I’ve since read on macworld.com that using that sudo command to force malware-definitions updates “can cause users to lose their login.keychain file.” (Thanks for the initial generally-broadcast advice to use that sudo command, Macworld.) I don’t yet actively use the Keychain for storing passwords, so I thought, no problem.
    When still at the computer right after that first, half-witted occasion, however, and switching between my standard account and the admin account, the desktop filled only about  80% of the display, from the upper-left corner; the remainder of the display below and to the right of the desktop was just plain blue screen. I’d never experienced THAT before. That got remedied by a restart (though I think I remember it happening that night when logging into both the admin and the standard-user accounts), but it has recurred often, seemingly now only when I log into the admin account. Each time it does happen, a restart fixes it. But I think it’s a result of my fiddling unknowingly with that sudo command, could that be?
    Next, a little more knowledge maybe yields some more trouble: I’ve tried, as admin user, to look at the Mac’s /etc/sudoers file to see whether it contains my admin, or any other recognizable user, but I get this response: “Permission denied” and ditto for trying to look at (or run) /private/etc/sudoers, private/etc//sudoers (which I saw referred to in these forums, I think, and wondered that it might NOT be a typo with those two slash marks together), cat /etc/sudoers. But I’ve read that admin users have sudoer permissions, no?
    Advice? (about damage from my Terminal sudo and botched-exit misadventure, the 80% desktop in the display, my inability to access the sudoers files)

    The problem with the display seems to have occurred when logging out from one account (either my standard-user acct. or my admin acct.) and (though maybe just sometimes, not always) into another account. I hadn’t checked the screen resolution until following your suggestion, and found it at 1440 x 1052 (stretched) when in that ~80%-of-normal condition. This display’s nominal resolution is 1680 x 1050. When 1440 x 1052 (stretched) resolution is chosen normally, however, the desktop or login screens appear symmetrically onscreen, centered and using the full extent of the display, unlike how they appear when this problem occurs “on its own.” Since resetting the resolution (when the display was in that problematic state) to 1680 x 1050, last week, the problem hasn’t recurred, through several logouts and logins between these two accounts, in a couple of different sessions. Thanks for the helpful advice.
    The F9 key function doesn’t seem to have had anything to do with this display problem. Your wondering about that, though, and the advice in your last two paragraphs, are worth my attention generally. I appreciate the links to Apple’s instructions on resetting PRAM, NVRAM, and the SMC.
    So, the display problem that may or may not have come up from my half-baked Terminal session seems solved, but my worry or wondering remains over what may have occurred from my sudo fiddling to get malware definitions updated. And why my admin account can’t access the sudoers file, and whether that’s another problem, I dunno, and I don’t have a lot of time to be getting into finding out, yet. I wonder whether I should just reinstall the OS and start fresh.

  • HT4103 have a problem with shared file does not exist? used sudo but "no file in directory". i think the problem is from when i tried to move itunes files to an external drive to save space on laptop, cant remember what i actually did!

    followed support steps  (sudo) to recover itunes sync authorization "permission error" but did not work

    i tried both steps but did not help: "disk utility" first aid and iTunes: Missing folder or incorrect permissions may prevent authorization.

  • [SOLVED] How to get sudo and kdesu to honor my user password?

    Hi folks,
    Well, I must be missing something. I think I've tried everything listed here https://bbs.archlinux.org/viewtopic.php?id=143487 and in the referenced links, but I still have the problem of my system rejecting my password for some uses of sudo and kdesu but not others.  I've included my /etc/sudoers file below.
    My problem may be due to screwing around with users:  I started out using bruce (1000), then switched to bbraley (1001), then deleted bruce in kusers, then changed bbraley to 1000. When that created more problems without solving the original one, I switched back to 1001.  I've played with adding and removing my user from groups, including creating a sudo group, making sure I am a member of wheel group, etc. 
    What seemed to be everyone's magic fix,
    pacman -S pambase
    didn't work when I tried it successfully with my bbraley password, then later, when that began failing, using the root password. pambase reinstalls, but there is no resulting change in the behavior of sudo.
    Side question: Most of my experience is with kubuntu in which I never created a root user and never had any trouble having my user password work with sudo or kdesu. Is there a reason Archwiki beginners guide suggests assigning a separate root account and password?
    Can anyone help?
    Here's the output of
    groups
    root adm disk wheel log locate network video audio optical storage scanner power users nm-openconnect systemd-network bbraley sudo sddm
    Here's the output of
    cat /etc/group |grep `id -un`
    root:x:0:bbraley
    adm:x:4:root,daemon,bbraley
    disk:x:6:root,bbraley
    wheel:x:10:root,bbraley
    log:x:19:root,bbraley
    locate:x:21:bbraley
    network:x:90:bbraley
    video:x:91:bbraley
    audio:x:92:bbraley
    optical:x:93:bbraley
    storage:x:95:bbraley
    scanner:x:96:bbraley
    power:x:98:bbraley
    users:x:100:bbraley
    systemd-network:x:193:bbraley
    nm-openconnect:x:104:bbraley
    sddm:x:619:bbraley
    bbraley:x:500:
    sudo:*:501:bbraley
    Here's what
    ls -l /etc/sudoer
    yields:
    -r--r----- 1 root root 2948 Mar 22 07:25 /etc/sudoers
    And here's my sudoers file:
    ## Defaults specification
    ## You may wish to keep some of the following environment variables
    ## when running commands via sudo.
    ## Locale settings
    # Defaults env_keep += "LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET"
    ## Run X applications through sudo; HOME is used to find the
    ## .Xauthority file. Note that other programs use HOME to find
    ## configuration files and this may lead to privilege escalation!
    # Defaults env_keep += "HOME"
    ## X11 resource path settings
    # Defaults env_keep += "XAPPLRESDIR XFILESEARCHPATH XUSERFILESEARCHPATH"
    ## Desktop path settings
    # Defaults env_keep += "QTDIR KDEDIR"
    ## Allow sudo-run commands to inherit the callers' ConsoleKit session
    # Defaults env_keep += "XDG_SESSION_COOKIE"
    ## Uncomment to enable special input methods. Care should be taken as
    ## this may allow users to subvert the command being run via sudo.
    # Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE QT_IM_SWITCHER"
    ## Uncomment to enable logging of a command's output, except for
    ## sudoreplay and reboot. Use sudoreplay to play back logged sessions.
    # Defaults log_output
    # Defaults!/usr/bin/sudoreplay !log_output
    # Defaults!/usr/local/bin/sudoreplay !log_output
    # Defaults!REBOOT !log_output
    ## Runas alias specification
    ## User privilege specification
    root ALL=(ALL) ALL
    ## Uncomment to allow members of group wheel to execute any command
    ##%wheel ALL=(ALL) ALL
    ## Same thing without a password
    %wheel ALL=(ALL) NOPASSWD: ALL
    ## Uncomment to allow members of group sudo to execute any command
    %sudo ALL=(ALL) ALL
    bbraley ALL=(ALL) ALL
    ## Uncomment to allow any user to run sudo if they know the password
    ## of the user they are running the command as (root by default).
    Defaults targetpw # Ask for the password of the target user
    ALL ALL=(ALL) ALL # WARNING: only use this together with 'Defaults targetpw'
    ## Read drop-in files from /etc/sudoers.d
    ## (the '#' here does not indicate a comment)
    #includedir /etc/sudoers.d
    Last edited by Bruce1956 (2015-03-28 05:16:03)

    Trilby wrote:I've never used the targetpw setting, but I wouldn't be surprised if that was the problem.  With that setting, if you want to run something as root (the default use of sudo) then you'd need the root password, not the user password.  Comment out that setting, and the next line.
    I had never used it, either, but I misread some reference and thought it might help. Since you say it causes the behaviour I'm trying to eliminate, I will get rid of it, as suggested. However, the behavior preceded my addition of this line in the file, so I don't think this will correct the problem. Edit: Removing it kept the root password from being universally required (I can now edit /etc/sudoers using my user password) and returned it to requiring it sometimes (I still need the root password to use kdesu).
    As for some other distro not having a root account, that is simply impossible.  There was a root account.  If you didn't have the password for it, then that installation was severely crippled.
    Sorry, you're right. I should have said that kubuntu does not expect users to assign a password to the root account and instead expects primary users to access that account's privileges via su, sudo, or kdesu only.
    https://help.ubuntu.com/community/RootSudo
    By default, the root account password is locked in Ubuntu. This means that you cannot login as root directly or use the su command to become the root user. However, since the root account physically exists it is still possible to run programs with root-level privileges. This is where sudo comes in - it allows authorized users (normally "Administrative" users; for further information please refer to AddUsersHowto) to run certain programs as root without having to know the root password.
    Thanks for responding to my request for help. Any other ideas?
    Edit:  Here's what I keep getting that only accepts the root password, not my user password
    http://s15.postimg.org/4z0o86oln/Runasroot_KDEsu.png
    -- mod edit: read the Forum Etiquette and only post thumbnails http://wiki.archlinux.org/index.php/For … s_and_Code [jwr] --
    Last edited by Bruce1956 (2015-03-23 04:41:06)

  • Is there any way to remove "sudo" from the server?

    sudo can do a lot of things which root can do. I tried the following to remove, but got failed message. Is there any graceful way?
    Or, maybe I don't have to remove it, by default, nobody can use sudo to run root only commands, unless I give them priviledge to do so by using "visudo", right?
    Please advice, Thanks!
    Edited by: 943714 on Aug 27, 2012 11:59 AM

    The idea of the sudo command is to give a user root access without the need to tell them the root password. When the user is not already root the sudo command will ask the user for the current user account password. This is to prevent that someone uses the sudo command in case your session gets hijacked. There is usually a default timeout. As long as you enter another sudo command within 5 minutes of the last sudo command, you won't have to enter your password.
    The visudo command is typcially used to edit the /etc/sudoers file, which defines which users or groups are allowed to use the sudo command and to which commands or group of commands it applies. For instance if you make an entry in the /etc/sudoers file to allow a certain user to use all commands, then the user can enter "sudo su -" to become root without having to know the root password.
    Edited by: Dude on Aug 27, 2012 12:47 PM

  • Hi, the problem of deleting files / videos seeds desktop to go into Terminal and then sudo rm-rf ~ /. Trash Pohangina the answers I've had e of someone in her forum but when I write procedures line in Terminal as the Krever my password and it can not writ

    Hi, the problem of deleting files / videos seeds desktop to go into Terminal and then sudo rm-rf ~ /. Trash Pohangina the answers I've had e of someone in her forum but when I write procedures line in Terminal as the Krever my password and it can not write anything there, I write but nothing comes and my problem is not löst.När I want to delete the movie / video image Frin desktop still arrive Finder wants to make changes.Type your password to allow this. But even that I type my password file / video is left I need help in an easier way or another set-even those on the terminal that I can not type my password to solve the problem Regards Toni

    If you want to preserve the data on the boot drive, you must try to back up now, before you do anything else.
    There are several ways to back up a Mac that isn't fully working. You need an external hard drive to hold the backup data.
    1. Boot from the Recovery partition or from a local Time Machine backup volume (option key at startup.) Launch Disk Utility and follow the instructions in this support article, under “Instructions for backing up to an external hard disk via Disk Utility.”
    2. If you have access to a working Mac, and both it and the non-working Mac have FireWire or Thunderbolt ports, boot the non-working Mac in target disk mode. Use the working Mac to copy the data to another drive. This technique won't work with USB, Ethernet, Wi-Fi, or Bluetooth.
    3. If the internal drive of the non-working Mac is user-replaceable, remove it and mount it in an external enclosure or drive dock. Use another Mac to copy the data.

  • [SOLVED] Unable to use SUDO: issues with /etc/sudoers

    I have reinstalled Arch_64 and I have run into some problems with SUDO.
    I get the following errors when I try to use sudo:
    sudo : unable to stat /etc/sudoers : Permission Denied
    sudo : no valid sudoers sources found, quitting
    sudo : unable to initialize policy plugin
    Here's what I have done with it so far:
    * I added USERNAME (myself) to the 'wheel' group
    * I uncommented %wheel ALL=(ALL) All using visudo
    As it was not working for me I also:
    * # chown -c root:root /etc/sudoers
    * # chmod -c 0440 /etc/sudoers
    * Since that too did not work, I recommented %wheel and added USERNAME ALL=(ALL) ALL just under the line root ALL=(ALL) ALL and repeated the above steps. The above problem persists.
    * I checked with visudo -c and it says "/etc/sudoers parsed ok".
    I have been through the WIKI and the forums but still unable to figure out whats going wrong.
    I will appreciate if the forum can guide me to solution and help me resolve this issue.
    Thanks.
    Last edited by fantab (2012-11-20 09:00:56)

    Had exactly the same problem with a new Arch_64 install a few months ago, which turned out to be a problem with permissions on / (which i changed with chmod) - can't remember the details, but it was this post that put me on to a solution:
    http://archlinuxarm.org/forum/viewtopic … =20#p19727

  • [SOLVED] Really need to install sudo to makepkg?

    Hi!
    Been using dwm for a couple of weeks, compiling it every time I made changes with no issues.
    Today, while trying to do it again, I am prompt to type a password: root pasword is not accepted, and If I type my own password, it says I am not (logically) in the suddoers file.
    I would prefer to login as su instead of using sudo, but don't know how to get makepkg run.
    Thanks in advanced,
    jm
    [jm@myArch dwm]$ makepkg -efi --skipinteg
    ==> Creando el paquete: dwm 5.9-2 (lun ene 2 17:11:12 CET 2012)
    ==> Resolviendo dependencias...
    ==> Verificando conflictos...
    ==> PRECAUCIÓN: Saltando obtención de fuentes -- usando el árbol src/ existente
    ==> PRECAUCIÓN: Saltando pruebas de integridad -- usando el árbol src/ existente
    ==> PRECAUCIÓN: Saltando extracción de las fuentes -- usando el árbol src/ existente
    ==> Eliminando el directorio pkg/ existente...
    ==> Iniciando build()...
    dwm build options:
    CFLAGS = -std=c99 -pedantic -Wall -Os -I. -I/usr/include -I/usr/include/X11 -DVERSION="5.9" -DXINERAMA
    LDFLAGS = -s -L/usr/lib -lc -L/usr/lib/X11 -lX11 -L/usr/lib/X11 -lXinerama
    CC = cc
    CC dwm.c
    dwm.c:822:1: aviso: se define ‘enternotify’ pero no se usa [-Wunused-function]
    CC -o dwm
    ==> Entrando a un entorno fakeroot...
    ==> Iniciando package()...
    dwm build options:
    CFLAGS = -std=c99 -pedantic -Wall -Os -I. -I/usr/include -I/usr/X11R6/include -DVERSION="5.9" -DXINERAMA
    LDFLAGS = -s -L/usr/lib -lc -L/usr/X11R6/lib -lX11 -L/usr/X11R6/lib -lXinerama
    CC = cc
    installing executable file to /home/jm/dwm/pkg/usr/bin
    installing manual page to /home/jm/dwm/pkg/usr/share/man/man1
    ==> Limpiando la instalación...
    -> Eliminando otros archivos...
    -> Comprimiendo las páginas man e info...
    -> Quitando los símbolos no requeridos de los binarios y bibliotecas...
    ==> Creando el paquete...
    -> Generando el archivo .PKGINFO...
    -> Añadiendo install archivo...
    -> Comprimiendo el paquete...
    ==> Saliendo del entorno fakeroot.
    ==> Terminado haciendo: dwm 5.9-2 (lun ene 2 17:11:15 CET 2012)
    ==> Instalando el paquete dwm con pacman -U...
    Contraseña:
    Sorry, try again.
    Contraseña:
    jm is not in the sudoers file. This incident will be reported.
    ==> PRECAUCIÓN: Error al instalar el/los paquete(s) compilado(s).
    Last edited by jmvidalvia (2012-01-02 17:04:39)

    karol wrote:When posting on the forum, please prepend your commands with LC_ALL=C so that the output is in English.
    Sorry for the unpoliteness: I did't know that option.
    Just created the sudo group, add my user to it, edit /etc/sudoers with visudo to allow this group.
    Thanks!
    PS: strange it is the first time I need to add my user to suddoers after so many compilations...

  • [SOLVED] alias with sudo: Password request malfunction

    Okay so here are two cool little system-maintenance related aliases, as suggested by "pacman tips" Wiki:
    Show dirs not owned by any package:
    alias pacman-disowned-dirs="comm -23 <(sudo find / \( -path '/dev' -o -path '/sys' -o -path '/run' -o -path '/tmp' -o -path '/mnt' -o -path '/srv' -o -path '/proc' -o -path '/boot' -o -path '/home' -o -path '/root' -o -path '/media' -o -path '/var/lib/pacman' -o -path '/var/cache/pacman' \) -prune -o -type d -print | sed 's/\([^/]\)$/\1\//' | sort -u) <(pacman -Qlq | sort -u)"
    Show files not owned by any package:
    alias pacman-disowned-files="comm -23 <(sudo find / \( -path '/dev' -o -path '/sys' -o -path '/run' -o -path '/tmp' -o -path '/mnt' -o -path '/srv' -o -path '/proc' -o -path '/boot' -o -path '/home' -o -path '/root' -o -path '/media' -o -path '/var/lib/pacman' -o -path '/var/cache/pacman' \) -prune -o -type f -print | sort -u) <(pacman -Qlq | sort -u)"
    typically I edit those into my "/etc/bash.bashrc" instead of "~/.bashrc", but there's no difference there. The thing is, when I invoke this alias,
    as regular user, it promptly requests [sudo] password, as it should, but after a brief moment the console returns to normal, there's no time for to even input the password, like this:
    [danilo@dandelion ~]$ pacman-disowned-dirs
    [sudo] password for danilo:
    [danilo@dandelion ~]$
    PS: If my password is still cached, it will work normally (my timeout is set to 30 min).
    here's my "/etc/bash.bashrc" at any rate:
    # /etc/bash.bashrc
    ## If not running interactively, don't do anything ##
    # [[ $- != *i* ]] && return
    ## Prompt display configurations ##
    set_prompt () {
    local last_command=$? # Must come first!
    PS1='\[\e[1;33m\]'
    if [[ $last_command != 0 ]]; then
    PS1+='$?'
    fi
    if [[ $EUID == 0 ]]; then
    PS1+='\[\e[1;31m\][\u@\h \W]\$\[\e[0m\] '
    else
    PS1+='\[\e[1;34m\][\u@\h \W]\$\[\e[0m\] '
    fi
    PROMPT_COMMAND='set_prompt'
    PS2='> '
    PS3='> '
    PS4='+ '
    ## Original default configs ##
    case ${TERM} in
    xterm*|rxvt*|Eterm|aterm|kterm|gnome*)
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'
    screen)
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033_%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'
    esac
    ## File sourcing ##
    [ -r /usr/share/bash-completion/bash_completion ] && . /usr/share/bash-completion/bash_completion
    ## Functions ## {{{
    ## Aliases ## {{{
    # Privileged access #
    if [ $UID -ne 0 ]; then
    alias sudo='sudo '
    alias scat='sudo cat'
    alias svim='sudoedit'
    alias root='sudo -i'
    alias reboot='sudo systemctl reboot'
    alias poweroff='sudo systemctl poweroff'
    alias update='sudo pacman -Su'
    alias netctl='sudo netctl'
    fi
    # listing #
    alias ls='ls -hF --color=auto'
    alias lr='ls -R' # recursive ls
    alias ll='ls -l'
    alias lall='ls -la'
    alias la='ll -A'
    alias lx='ll -BX' # sort by extension
    alias lz='ll -rS' # sort by size
    alias lt='ll -rt' # sort by date
    alias lm='la | more'
    # Show dirs that do not belong to any package #
    alias pacman-disowned-dirs="comm -23 <(sudo find / \( -path '/dev' -o -path '/sys' -o -path '/run' -o -path '/tmp' -o -path '/mnt' -o -path '/srv' -o -path '/proc' -o -path '/boot' -o -path '/home' -o -path '/root' -o -path '/media' -o -path '/var/lib/pacman' -o -path '/var/cache/pacman' \) -prune -o -type d -print | sed 's/\([^/]\)$/\1\//' | sort -u) <(pacman -Qlq | sort -u)"
    # Show files that do not belong to any package #
    alias pacman-disowned-files="comm -23 <(sudo find / \( -path '/dev' -o -path '/sys' -o -path '/run' -o -path '/tmp' -o -path '/mnt' -o -path '/srv' -o -path '/proc' -o -path '/boot' -o -path '/home' -o -path '/root' -o -path '/media' -o -path '/var/lib/pacman' -o -path '/var/cache/pacman' \) -prune -o -type f -print | sort -u) && <(pacman -Qlq | sort -u)"
    Last edited by DVNO (2014-08-12 05:12:57)

    You'd suppose it would work, but no, same error... Perhaps it traces back to some other configuration file...
    By the way, the second command, I didn't paste it correctly; There's no "&&" before the pacman query part of the command. Fixing the post now...
    Well, anyways, I believe I got'em working, I appended a useless command that requires elevation AND works properly, like this:
    alias pacman-disowned-dirs="sudo true && comm -23 <(sudo find / \( -path '/dev' -o -path '/sys' -o -path '/run' -o -path '/tmp' -o -path '/mnt' -o -path '/srv' -o -path '/proc' -o -path '/boot' -o -path '/home' -o -path '/root' -o -path '/media' -o -path '/var/lib/pacman' -o -path '/var/cache/pacman' \) -prune -o -type d -print | sed 's/\([^/]\)$/\1\//' | sort -u) <(pacman -Qlq | sort -u)"
    And:
    alias pacman-disowned-files="sudo true && comm -23 <(sudo find / \( -path '/dev' -o -path '/sys' -o -path '/run' -o -path '/tmp' -o -path '/mnt' -o -path '/srv' -o -path '/proc' -o -path '/boot' -o -path '/home' -o -path '/root' -o -path '/media' -o -path '/var/lib/pacman' -o -path '/var/cache/pacman' \) -prune -o -type f -print | sort -u) <(pacman -Qlq | sort -u)"
    ...Still, it's a r@t workaround, not a proper solution, so I'll ask to not mark this as solved yet. Maybe someone can backtrack this properly.
    Thank you, for the quick reply, much appreciated.

Maybe you are looking for