Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Pages: 1
Can someone verify this seemingly dangerous behavior?
I did a chmod o-w on /mnt/HD_a2
When I rebooted I found that ALL files in the directory tree were now user/group/other writable!!!!
In addition to being a security hole, it made my box inaccesible since the ssh keys were now readable leading sshd to fail to start.
It seems to me to be very reasonable to restrict permissions on the root directory of the volume. But obviously the dns-323 doesn't like this.
Any suggestions on what to do or am I missing something obvious here?
Offline
Offline
Fonz - thanks for the reference and all the help. Maybe this should be added to the known issues sticky and wikipedia entry since it is a very non-obvious "gotcha" that you otherwise don't become aware of until too late when you find yourself locked out and have your permissions destory.
Second, doesn't this create a giant bus-sized hole in security, since now anybody who has shell access (telnet or ssh) can just cd to root and remove things like the ffp directory?
Even worse, since the web-based network access creates user passwords, anyone with samba access will have by default ability to create a shell and thus literally get root access.
I noticed in your suggested link a reference to doing a chroot before runing init but I am not sure where to put this and whether this would even work in a fun_plug situation vs. a full linux replace.
So what are the current best to plug this whole if you don't want to use a full custom firware or linux?
Offline
Here is a one-liner script that will reset the permissions based on a (clean) reference package:
(base="/"; IFS=$'\n'; for file in `tar tvz -f <package-name.tgz>`; do perm=`echo $file | sed -ne "s/^[^l]\([-rwxsStT]\{3\}\)\([-rwxsStT]\{3\}\)\([-rwxsStT]\{3\}\).*/u=\1,g=\2,o=\3/p" | tr -d '-'`; name=`echo $file | sed -ne "s/^[^l].* [0-9]\{4\}-[0-9]\{2\}-[0-9]\{2\} [0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\} \(.*\)/\1/p"` ; [ ! -z $perm ] && [ ! -z $name ] && chmod -c $perm ${base}${name}; done)
Now I think that sets a *personal* record on most complicated shell one-liner
Offline
OK there is a small problem with the above script with hard links. The problem is that a hard link in this version of tar is not indicated with a 'h' file type. Thus the legal but weirdly named file "link -> file" looks the same in tar as a hard link. But since hard links are common and weird file names with a "->" surrounded by single spaces is not, I will modify the script to identify any tar line with " -> " as a hard link.
(base="/"; IFS=$'\n'; for file in `tar tvz -f <package-name.tgz>`; do perm=`echo $file | sed -ne "s/^[^l]\([-rwxsStT]\{3\}\)\([-rwxsStT]\{3\}\)\([-rwxsStT]\{3\}\).*/u=\1,g=\2,o=\3/p" | tr -d '-'`; name=`echo $file | sed -ne "s/^[^l].* [0-9]\{4\}-[0-9]\{2\}-[0-9]\{2\} [0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\} \(\(.*\)\( -> .*\)\|\(.*\)\)/\2\4/p"` ; [ ! -z $perm ] && [ ! -z $name ] && chmod -c $perm ${base}${name}; done)
Offline
Wondering whether it might be a good idea to add a line to the various shutdown scripts to change partition roots to mod 777.
For some reason, I keep doing dumb things with rsync that changes the permissions of the root directory without realizing it!
Offline
Pages: 1