Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Pages: 1
So this is somewhat of a dumb user error, but it's also quite subtle in nature. I have fun_plug installed on my DNS-323 so that I could install Twonky, and I'd configured a root user password and saved it to the firmware as described in the fun_plug HOWTO. The other day I noticed that some of the permissions on the drive weren't as expected, so I updated the permissions on the user folders properly to match. In the process of doing so, I noticed a typo in my wife's username on the DNS-323 and deleted/re-added her username and updated the files that should be owned by her user ID for the new one. So far, so good.
However, in the process of doing so, I think the Web admin software for the DNS-323 undid my root user's password information when it updated the firmware password/shadow files and now I can't log back in as root on that machine. I can log in as my user and my wife's user, as well as the "admin" user for the DNS-323, but just not root. Unfortunately, none of those users are even in the "root" group, so I have no write access to anything that I could use to fix the situation to the best of my knowledge.
I was hoping I could change the telnet shell to "sh" again or something, or even automate a password change by appending something like the following to the end of my fun_plug script or one of those that it launches:
passwd <<-EOT
<password>
<password>
EOT
but as you'd expect, only the root user has write access to ANY of those files.
I've thought about an extreme scenario of popping out the drives and putting them into another Linux box so that I can edit the fun_plug scripts to give me access without a password again, then popping them back in so that when the DNS-323 comes up I can use it, but I'm not sure how software ext2fs works in terms of what it would mean to read those disks in another machine. I assume that since it's ext2fs and the root user ID always matches, I should just be able to edit as the other machine's locale root user, but I'm just not 100% sure.
Does anyone have a good suggestion for how I might make this situation right without having to whack the contents of those disks?
Thanks in advance!
Scott
Offline
Back up the config files you want to keep (you can still read fun_plug.d/etc, right?) and copy a fresh fun_plug.tar to Volume_1. If all goes well, it'll overwrite your telnet script...
Offline
fun_plug.d is 755 or maybe 775 for root:root across the board, I believe. I'll verify when I get home, but I think that was the case. Again, I think this was me locking things down, probably not from the original distribution.
Offline
Depending on your setup there may be alternative approaches, e.g. http://dns323.kood.org/forum/p6000-2007 … html#p6000
Offline
Ah, fantastic! I'll see what I can do along those lines. Thanks so much!
Offline
Unfortunately the only fun_plug services I have running are telnetd and twonky, so I don't have an opportunity to drop a script into a Web root or anything. Unless there are other options for such backdoor hacks, I'll likely just pull the disks and put them into another machine here so I can change login to use sh instead of telnet so I can set the root password again. Thanks for the help!
Offline
I haven't tried that yet, but like I said, fun_plug and fun_plug.d are owned by root:root and are chmod 755, so I'm not sure how that'll work. I'll try it when I'm home again this evening, but the user IDs of the client machines are not root for sure.
Offline
It's supposed to work as it did during installation. You put a fun_plug.tar into Volume 1 and reboot. The fun_plug script will find it and unpack all the files. It does this as root, so it can overwrite whatevert files there are with the versions from the tar. It, of course, includes the original version of start/telnetd.sh that doesn't ask for a password. Et voila...
Offline
That did it, fonz! Actually it did require a bit of tinkering as my original fun_plug had a different directory structure and start script naming convention (telnetd.sh vs. 00telnetd.sh and no SBINDIR env var being set by my fun_plug script), but by unpacking the tarball, editing 00telnetd.sh, and putting the updated version out there, it did what I needed. Thanks so much for the help! I'm back in a very good state now.
Offline
Hello,
I found a sort of minimal way to install telnetd using fonz'z funplug-0.4 as per my fun_plug script below. My basic requirement is a minimal telnet for root only, and through which I can unmount the file system for checking and so on.
Enjoy
Jaya
#!/bin/sh # manifests root=/home/root disk=/mnt/HD_a2/fun_path logs=/mnt/HD_a2/fun_logs export PATH=.:$PATH # switch to disk path cd $disk { # boot timestamp busybox date # execution trace set -x # install files busybox cp busybox $root # replace shell busybox mv -f /bin/sh /bin/sh.old busybox ln -s $root/busybox /bin/sh # establish console busybox mknod -m 0666 /dev/ptmx c 5 2 busybox mkdir -p /dev/pts busybox mount -t devpts devpts /dev/pts } >$logs 2>&1 # switch to root path cd $root # setup telnet policy busybox sed -n -e '/^root:/s|:/.*|:/home/root:/bin/sh|p' /etc/passwd >passwd busybox sed -e '/^root:/d' -e 's|:/.*|:/:/bin/sync|' /etc/passwd >>passwd busybox mv passwd /etc/passwd busybox echo "/etc/passwd updated" >>$logs # clone admin password busybox sed -n -e '/^admin:/s//root:/p' /etc/shadow >shadow busybox sed -n -e '/^root:/dp' /etc/shadow >>shadow busybox mv shadow /etc/shadow busybox echo "/etc/shadow updated" >>$logs # start telnet daemon busybox telnetd -l /bin/login -F busybox echo "telnet daemon started" >>$logs
Offline
Hi!
Linux-noob as I am, the same thing happened to me. I fixed it with uploading a new tarball like you said fonz, thank you for that:)
My question is what caused this? Should I not mix managing accounts in the web UI and by telnet/ssh? If not, how do I manage the ftp accounts and and their access from the shell?
//T
Offline
At this point my assumption is that when you manage accounts in the Web UI, you should have an active root shell open from which you set and store your password again immediately upon completion of account management. As we both now know, you can drop a new tarball in the root directory again to get back in, but given that things move around over time as with my experience (the startup scripts and sbin dir), it's probably safer just to make that a point of process.
Offline
Yes, probably.
But how do you manage ftp-accounts, access and settings by telnet/ssh?
I have only just started with linux I'm not even quite sure how the accounts types are connected. The ftp accounts are the same (as the very same instances, not even duplicates) accounts and passwords used to log on to the computer right?
//T
Offline
ojve wrote:
But how do you manage ftp-accounts, access and settings by telnet/ssh?
Hello,
I hope you are aware managing passwords through telnet/ssh will not be persistent across reboots unless you use fonz's scripts or equivalent to write these changes to flash. If you are doing this, you also have to be careful not to interfere with the mount/umount of flash device by the web interface.
I prefer to make changes in memory and let the web interface take care of committing these to flash.
Regards,
Jaya
Offline
jayas wrote:
I hope you are aware managing passwords through telnet/ssh will not be persistent across reboots...
You can also use a technique where the 'managed' passwords are stored in a file
and copied over the working root via a script at startup. Similar to the last few
lines in jayas script in post 65.
Last edited by mig (2008-03-07 09:49:53)
Offline
mig wrote:
You can also use a technique where the 'managed' passwords are stored in a file
and copied over the working root via a script at startup. Similar to the last few
lines in jayas script in post 65.
I am wondering if backing up the configuration, editing what we needs to be customised, and then reloading the customised profile would be the best method, assuming of course the backup and restore of configuration works reliably.
Incidentally the backup configuration files holds email password in the clear! So much for password security.
Jaya
Offline
jayas wrote:
I am wondering if backing up the configuration, editing what we needs to be customised, and then reloading..
This is certainly a possible technique; however, you are still relying on
(closed source) D-link provided software to read the configuration file and update
the system/memory files. If you add something in your customization that
the configuration file reader doesn't handle, it could lead to unexpected results.
Offline
mig wrote:
This is certainly a possible technique; however, you are still relying on
(closed source) D-link provided software to read the configuration file and update
the system/memory files. If you add something in your customization that
the configuration file reader doesn't handle, it could lead to unexpected results.
True. Digressing ....
I am wondering [only wondering at the moment ... ] that given the configuration backup file format appears very similar to another product I have looked into (router from another vendor), the origins of the parser could be from a 'common' or even 'not so open' source. I wonder if anyone else has seen the configuration files.
We could try ask D-LINK to release source for their goweb interface but I reckon it would not be a good idea to for one to hold one's breath waiting for this
Jaya
Offline
Hello,
This is a follow-up to my previous post. I must caution that this post in no way suggests you should not heed Mig's (IMO) good advice relating to changing configuration files.
I had been unhappy that the GUI interface would not allow me to restrict root share (Volume_1) to "admin" user only because this user does not come up in the list of users. So I created a dummy user, and allocated this share. Then I dumped the configuration file, and changed the user name for this share as follows:
[ Volume_1 ] comment = admin path = /mnt/HD_a2 valid users = admin read only = no guest ok = no oplocks = yes map archive = yes
It works and I am happy
Jaya
Last edited by jayas (2008-03-08 01:47:19)
Offline
Ok, so I tried to get some help on this but no one seems to know the answer, or bother to take the time to answer.
So, if I'm supposed to continue to do user management from the web UI, does anyone have any idea exactly when theses changes will interfere with the root password?
I'm going away and would like to be able to do all management of my disks remotely. Is there any other (secure) way than to install openVPN and do it from the web UI. To be honest, the instructions for openVPN seemed a bit advanced for me.
Please help
//T
Offline
Pages: 1