Saturday, February 23, 2013

Executing sudo as a non-admin user in macOS (OS X) and fixing "getcwd: cannot access parent directories" error

This is a weird one.

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 ls
That 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 Fred
to 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 Kateva
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
bash-3.2$ ls
ls: .: Permission denied
I 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 -- but as with every other time I'ver repaired permissions that produced many changes but no results. (It doesn't act on user folders.)

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:

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/
chmod 644 !$
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.

Now su works as it should.


Anonymous said...

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.

Anonymous said...

This openid login thing isn't working the way it used to... weird.