According to what I read online and in the Man pages, I should also be able to do something like this (where Fred is Admin account):
sudo -u Fred lsThat should ask for Fred's password then execute ls with Fred's privileges.
Except it doesn't. It runs against my non-admin account and fails. As though it were ignoring the -u flag. Instead I have to run
su Fredto execute as Fred, then run sudo. [I think that su Fred sudo -u Fred ls should also work.]
I can't find anyone else who complains about this, so I assume I'm doing something wrong.
Note to test this you have to run from a non-admin account.
Update 8/23/2016: I can't get sudo to work at all in El Capitan for a non-admin users. Says: "error retrieving current directory: getcwd: cannot access parent directories: Permission denied."
Update 5/27/2018: I finally tried this in a different non-admin account. It works in Sierra in other accounts. So it wasn't El Capitan that broke this, it was something I did to my 18yo user account.
This is what I would see:
John-Air:~ myaccontname $ su KatevaI searched around SuperUser for a while and got some hints. I deleted every user account Bash preference I could find. That didn't do anything. I repaired MacOS Sierra permissions using Onyx.app -- but as with every other time I'ver repaired permissions that produced many changes but no results. (It doesn't act on user folders.)
Password:
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
bash-3.2$ ls
ls: .: Permission denied
bash-3.2$
Eventually I realized the most likely explanation was the simplest one -- I'd somehow messed up permissions on the default account for Bash. By experimenting on my "good" non-admin user account I realized Bash default directory is the User account. So I compared User Account permissions and found this:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh237TFhEUQwDWdvu3cUYYacyWMbft34xUR7muOtXIjGBO_wVxj7HPP_YWmgO5aNv5izeHh2KNDuCShKB1gQMWtsyQ2EReGadVB2hAeO13-_s5GcWvWyHO4Iv61gL18MAITWgya/s400/permissions.png)
The problem directory was readable by 'everyone' but not by 'staff'. You'd think that 'everyone' would work ... but read this and weep. macOS permissions are a disaster. Don't even think about ACLs. It's a sign of the end-times really.
I couldn't see how to restore Staff. In the old days there was a utility for this, but that's long gone. Somewhere I found this advice to restore staff:
Now su works as it should.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh237TFhEUQwDWdvu3cUYYacyWMbft34xUR7muOtXIjGBO_wVxj7HPP_YWmgO5aNv5izeHh2KNDuCShKB1gQMWtsyQ2EReGadVB2hAeO13-_s5GcWvWyHO4Iv61gL18MAITWgya/s400/permissions.png)
The problem directory was readable by 'everyone' but not by 'staff'. You'd think that 'everyone' would work ... but read this and weep. macOS permissions are a disaster. Don't even think about ACLs. It's a sign of the end-times really.
I couldn't see how to restore Staff. In the old days there was a utility for this, but that's long gone. Somewhere I found this advice to restore staff:
sudor chown $UID:staff /path/to/folder/modified/I ran it and staff was restored. When I logged back into my user account I was told macOS had to do something to enable me to run Applications! I entered my admin credentials and was asked again ... and again ... then I gave up and logged out. I logged back in and things .... seemed ... fine.
chmod 644 !$
Now su works as it should.
2 comments:
My understanding is that if the user you are trying to run sudo as is not in the sudoers file (admins are in there by default on OS X), then I don't think any sudo command will work at all.
This openid login thing isn't working the way it used to... weird.
Post a Comment