How to enter a directory with the 'cd' command if it has 700 permission and is not owned by me?

sudo cd won't work because the cd command is built into the shell. So you are saying become root and then run this command. You become root and then the command after sudo is searched for but there is no cd command to find.

The method to use is to switch to the user that owns the directory. Permission 700 is meant as "owner can read, write and execute".

So if root owns the directory sudo -i, password and then cd {dir} is the only correct method. If someone else owns the directory you can still use the 1st method but can also change to that user with su {username} and then use cd as that user.

sudo -i

to open "root console" and then

cd /path/to/directory

(cd is a shell builtin command, so it can't be the sudo target)

To open a root directory we may run a root shell, e.g.:

sudo su
# cd /root

As others pointed out -- it's shell built-in:

~ % which cd
cd: shell built-in command

So, why don't you sudo the shell itself?

~ % sudo $SHELL -c "cd name_of_dir"

You can also elevate yourself to root user by:

sudo -s

Then you can cd to any directory which doesn't allow normal user in like:

cd /root

Or

cd /var/lib/

Then after you're done in there type:

exit

To logout of the root user privileges.

For elevating yourself as root, you can also combine the two commands by && operator as below, this operator also maintains their execution sequence, if current command executes successfully and only then the next command is allowed to execute:

sudo -s && cd /var/lib

Or

sudo -s && cd /root

If you really want to make sudo cd directory work, you can define a bash shell function called sudo that runs a new root shell when run that way, and just runs the regular sudo command otherwise.

As presented in other answers, most users will not want to bother doing that, but will instead want to:

1. Run sudo -s, or sudo -i if you want a login shell (remember that one effect of sudo -i is to start you out in root's home directory), or sudo bash if you want to force bash or be able to pass options to the shell.
2. Run cd directory in the new shell.
3. Perform whatever (other) actions need to be taken as root in the new shell.
4. Once done, run exit to leave the new shell. It's important not to forget this, because you don't want to perform more actions as root than you intend!

So, if you want to, then you can write a shell function (or a script) that performs the first two of those actions when sudo is followed by cd, and just runs sudo normally otherwise. Please do not use this as an alternative to learning why sudo cd does not otherwise succeed, because if you don't understand what is going on, then you will likely be very confused by being in a new shell (and you may not understand any error messages that occur).

Here's one way to write such a shell function, which also reminds you that you're in a new shell and that you should exit out of it when you are finished. (That reminder is likely to be useful for users of any skill level, because one is not generally accustomed to being in a new shell when one runs sudo without -s, -i, or the name of an actual shell as an argument.)

# Make sudo treat "sudo cd [DIRECTORY]" as a special case and start a shell.
sudo() {
    if [ "$#" -eq 2 ] && [ "$1" = 'cd' ]; then
        sudo bash -c '
                if cd -- "$2"; then # When cd fails, its own message is enough.
                    printf "%s: Running %s shell in %s\n" "$0" "$USER" "$2" >&2
                    printf "%s: Type \"exit\" once you are done!\n" "$0" >&2
                    exec bash # Replace this bash shell with an interactive one.
                fi
            ' bash _ "$2" # Use $2 as the dir in the intermediate shell, too.
    else
        command sudo "$@"
    fi
}

You could put this in your ~/.bashrc, though this is a weird enough way to use sudo that you may only want to enable it occasionally. In that case, it's better to put it in its own file. If you create a file called sudo.bash in your home directory with those contents, then you can make the sudo function available--so that it will run instead of the regular sudo command--by running . ~/sudo.bash. That takes effect in the current shell and its child shells, but not others. For the same reason that files like .bashrc are not executable, don't mark sudo.bash executable with chmod. This is really a library, rather than a standalone shell script. If you did run it as a shell script, it would define the function... but only in the shell that ran the script, not for you as the caller. (Of course, you can write a script for this, that just doesn't happen to be the approach I've taken here.)

To check and see if sudo is currently defined as a shell function, and to see its current definition if it is one, run type sudo. To disable (i.e., undefine) the function once it's defined, run unset -f sudo. To manually run the regular sudo command directly even if the shell function is defined, run command sudo. Note, however, that you don't have to do that, because this sudo function actually does that itself whenever there are more or fewer than two arguments passed to it or the first argument passed to it is anything but cd. That's why you can still use it in the normal ways people use sudo.

Note also that the shell function shown above does still let you pass other arguments to sudo, but that will prevent it from treating cd specially. Running sudo -u user cd directory in particular is not supported, though you could extend the shell function to support that case. Nor is sudo -i cd directory. The shell that it creates is similar to what you get with sudo -s. The code does not actually run sudo -s, but uses sudo bash, so the -c option works properly. It actually runs bash twice when you pass cd and a directory argument to it (and zero times otherwise). When you run sudo cd directory, first it forks off a separate bash shell from the one you're running the sudo function in and changes directory. If that succeeds, it replaces that bash shell with a new, interactive one that you can use.

Here's an example of how that shell function automatically "does the right thing." Notice that sudo ls -A /root behaves normally. Only when I then attempt to cd to a directory with sudo is a new shell created, and I am reminded explicitly of what is going on.

ek@Io:~$ sudo ls -A /root
[sudo] password for ek:
.aptitude      .bashrc  .config  .emacs.d  .nano     .rpmdb
.bash_history  .cache   .dbus    .local    .profile
ek@Io:~$ sudo -k  # invalidates my current timestamp... like I left for a while
ek@Io:~$ sudo cd /root/.local
[sudo] password for ek:
bash: Running root shell in /root/.local
bash: Type "exit" once you are done!
root@Io:/root/.local#
root@Io:/root/.local#
root@Io:/root/.local# exit
exit
ek@Io:~$

If you try to sudo cd to a directory that you can't change to even as root, then you will just get an error message:

ek@Io:~$ sudo cd /nonexistent
[sudo] password for ek:
bash: line 1: cd: /nonexistent: No such file or directory
ek@Io:~$ sudo -k
ek@Io:~$ sudo cd /etc/crontab
[sudo] password for ek:
bash: line 1: cd: /etc/crontab: Not a directory
ek@Io:~$

I have used sudo -k in between invocations in the above examples to show that it authenticates you as root before attempting to change directory. But you don't actually have to run sudo -k yourself. Because the shell function is just a thin wrapper for the real sudo command, caching of your credentials and other common sudo behaviors still work normally.

Though it works well and is kind of neat, I admit that shadowing the real sudo command with a function of the same name is super weird. Most users will probably just want to perform the steps sudo -s, cd directory themselves. But in case anybody wants this--and also to demonstrate that it's possible--there it is.

As far as the to su or not to su debate, I think it's silly. su is against the religion of Ubuntu and it's not something to do carelessly. It's amazing what an rm -rf * can do if you're root. But, if you're comfortable with the command line interface (CLI) and have system level tasks to do, there's no reason not to use su. I've used several distros where no one even mentioned using sudo. It's just a matter of what kind of work you're doing and which method you're most comfortable with. I use both.

@Daniel Bauke's solution works when what you're trying to sudo is a compound command, such as cd /some/path && ./executableScript.sh which may be what you need if executableScript.sh needs to be executed from within its directory, and it requires sudo both to enter the directory and to run the script (and you want to do this in a non-interactive/session kind of way.

To reiterate, Daniel Bauke's solution is:

sudo $SHELL -c "cd /some/path && ./executableScript.sh"