# echo ************ | sudo -S route -n add 192.168.1.0/24 172.16.1.1 (dangerous)



## TomHsiung (Sep 3, 2018)

I plan to create a shell script to run this syntax automatically once my server startups.

However, this syntax requires root privilege.

I have to use echo command, but the password is in plain form. So it's not security, if some one got your shell script file. Anyway to fix this issue?

Tom


----------



## SirDice (Sep 3, 2018)

Why don't you use `static_routes` in /etc/rc.conf?


----------



## kpedersen (Sep 3, 2018)

You could also instruct sudo to allow a certain script without the password (via NOPASSWD). i.e

in /etc/sudoers (via visudo command)

```
<username>       ALL=(ALL) NOPASSWD: /obin/add_route
```

in /obin/add_route add your command and use the following boilerplate to "rerun" as root.

```
#!/bin/sh

if [ "`whoami`" != "root" ]; then
  exec sudo $0
fi

route -n add 192.168.1.0/24 172.16.1.1
```

and finally:

```
# chmod ugo+x /obin/add_route
```

Now <username> can just run `/obin/add_route` and it will automatically run itself again but via sudo which will also no longer ask for a password. It will then run your routing command.

if you find the boilerplate stuff hacky, just remove it and use `sudo /obin/add_route` instead.

What I might suggest is rather than using <username>, add that user to a group and then set group permissions in sudo instead. Then you can have control over entire groups of users allowed to change the routing config (operator or wheel might also be a good one).


----------



## TomHsiung (Sep 3, 2018)

I have searched and found an easy way to resolve this issue. Just change the owner and the directory permission to this:


```
drwsr-xr-t   4 root       staff       128 Sep  3 18:10 launch
```

When you run the script within the directory, you do not need the 
	
	



```
sudo
```
 prefix. It's relatively safer compared with the 
	
	



```
sudo -S
```
 method.


----------



## SirDice (Sep 3, 2018)

The SUID/SGID bit on directories doesn't work like you think it does. Besides that, the SUID bit (on directories) is ignored by default. 


```
4000    (the setuid bit).  Executable files with this bit set will
                   run with effective uid set to the uid of the file owner.
                   Directories with this bit set will force all files and sub-
                   directories created in them to be owned by the directory
                   owner and not by the uid of the creating process, if the
                   underlying file system supports this feature: see chmod(2)
                   and the suiddir option to mount(8).
```
See chmod(1).


----------



## TomHsiung (Sep 3, 2018)

It seems something is wrong. It did work.


```
Toms-MacBook-Pro:~ tomhsiung$ ls -lia ~/launch/
total 16
4056844 drwxr-xr-x   4 tomhsiung  staff   128 Sep  3 21:11 .
 687664 drwxr-xr-x+ 30 tomhsiung  staff   960 Sep  3 21:15 ..
4056948 -rw-r-xr-x@  1 tomhsiung  staff  6148 Sep  3 21:11 .DS_Store
4066625 drwsr-sr-x@  3 root       staff    96 Sep  3 21:11 netstat.app
```


```
Toms-MacBook-Pro:~ tomhsiung$ open -a ~/launch/netstat.app
LSOpenURLsWithRole() failed for the application /Users/tomhsiung/launch/netstat.app with error -10810.
```


----------



## SirDice (Sep 3, 2018)

MacOS is not supported here. 

Rule #7: FreeBSD Forums Rules

Thread closed.


----------

