Why doesn't `sudo cd /var/named` work? [duplicate]

The reason you can't do this is simple and two fold

1

cd is not a program but an in-built command and sudo only applies to programs.

sudo foo means run the program foo as root

sudo cd /path returns

sudo: cd: command not found

because cd is not a program.

2

If it were possible to use sudo to cd to a protected directory then having run the command sudo cd /var/named you would be in that directory as a normal user but normal users are not allowed to be in that directory.

This is not possible.

Workaround:

You can use sudo -i to elevate yourself to super user. For example:

sudo -i
cd /var/named 

You are now logged on as root and can use whatever commands you wish. When finished type exit and you are back to being logged on as a normal user.

That's because cd is not an executable, it's a shell function to change directory.

If you run:

type cd

your will get:

cd is a shell function

You can use sudo -s to open an interactive shell and then cd to to your desired directory:

sudo -s
cd /var/named

To return back to your normal shell simply hit Ctrl+D.

All of the answers above are correct; here's a workaround though

sudo sh -c "cd restricted-dir; some_command"

It's also worth remembering that, cd's status as a shell builtin or external binary notwithstanding, sudo works by spawning a new process to run the command specified.

Why is this important? Because the basic execution flow of sudo becomes something very similar to this:

1. The shell spawns off a subprocess to run sudo with the given parameters
2. sudo authenticates the user and confirms their right to execute the specified command
3. sudo spawns off a subprocess to execute the specified command
4. sudo waits for the subprocess spawned off in step 3 to exit
5. sudo exits, returning to the shell
6. The subprocess spawed in step 1 exits, returning the user to the shell prompt

(This may be technically slightly incorrect; there is a system call which actually replaces the running process with a new one (that's the C library's execve()). However, for the purposes of this explanation, the two are equivalent.)

This becomes important when you consider that the current working directory is a property of each process and is inherited but not promoted. So if process A spawns off a new process B, then process B starts with the same working directory that process A was in. (This is why something as mundane as ls ./ does what you'd expect.) But if process B changes its working directory, then unless process A goes out of its way looking for that, A is completely unaware of that change. (This, in turn, is why if you run something like find / and abort it half-way through, you don't end up in some seemingly random location in the file system just because find happened to be looking there at the moment it was aborted.)

So even if sudo cd /somewhere did exactly what it says on the tin, by the time sudo exits, you are brought right back where you started. Hence effectively from the point of view of the user, it becomes a no-op. The fact that cd, while it was executing, called the chdir() system library function to set a new working directory, doesn't help you, the user.

As Warren Hill pointed out, the proper solution (I actually wouldn't call it a workaround) is to use sudo -i which drops you to a root shell where you can navigate around the filesystem freely and execute whatever commands you feel like. Do note however that when you exit this shell, you are still brought right back where you started in the directory hierarchy for exactly the same reason as I described above.

You can also change the permission temporarily if you are a sudo user.

sudo chmod 0775 path

or

sudo chmod +r folderpath

Make sure you put it back if necessary.