Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
The dns-323 assigns admin and nobody the uid's 500 and 501 respectively.
Unfortunately, those are the uid's that I use for key user accounts on my Linux server which creates problems when I nfs-mount the dns-323.
Question is whether changing the uid's (and gid's) of admin and nobody via the store-passwd.sh will work or whether the firmware and gui have these account id's hardwired elsewhere.
Searching /dev/root, /sys/mtd1, /sys/mtd2, /dev/sda4 (/mnt/HD_a4), /dev/sdb4 (/mnt/HD_b4) and the unpacked initrd, I found that only one file has that uid/gid.
And that file is volatile (i.e. on /dev/root) and zero length:
crw-rw-rw- 1 nobody 501 1, 3 Dec 27 2005 /dev/null
so that should automatically be changed at the next reboot.
I am only asking out of paranoia that somehow the hack d-link code manually assumes numerical uid/gid in some of its code rather than using the corresponding names.
(also fun_plug has uid/gid 501/501 but that is easy to fix)
Offline
Hi puterboy,
I tried your proposal today, because I have also the same problem with unmatched UID/GID.
I made some trials with anonuid, but it did nor work. Next step was of course to change ids
manually on DNS site. But after reboot the ids were back and before reboot the rights for
reading/writing were not correct.
Before I startet your idea, I made a copy of all files are copied this script to a separate folder
in my home directory on DNS. Then I modified passwd, group, samba/smbpasswd acoording
my clients. After reboot of DNS all my modifications persist.
Regarding rights I am checking now. But I am quite optimistic.
Thanks for that idea, I think it will help to many users.
Joerg
Offline
Perhaps it's late - but not sure I completely understand what you wrote.
In the end did is it working? or did the uid/gid's get reset on reboot?
Also, I assume you used the store-passwd.sh script to right the changes to the passwd & group files to flash?
Offline
Hi,
yes, no reset after reboot. All reassigned UID/GID are still as I want.
One compromise I have to accept. User admin is assigned to be UID=500 and GID=500.
UID 500 is actually my middle name on clients, basically only used for testing of new software.
GID 500 is my family name and all family members are belonging to this group.
I do not want to reassign admin, because I can not estimate the consequences. So I am going
to establish a new family group on my clients.
Back to question: yes - I was using store-passwd.sh.
CU - Joerg
Offline
Thanks.
Can you check the ownership of /dev/null?
Because the rc.sh init script *explicitly* does a:
chown 501:501 /dev/null
This could be problematic if it is now assigned to you but other (non-privileged) users attempt to run stuff directly on the NAS. Note this shouldn't affect people just using the NAS functionality without logging on since most of those operations are done with services that are either root or suid root.
The binary files: /sys/crfs/web/S_DOWN, /sys/crfs/web/webs also have strings of form "chown -R 501:501".
The webs file also mentions user 500 in a password-like format. Maybe for access to the web server?
So, I'm not sure anymore about what (hidden) problems may arise to bite...
Finally, make sure you also change /etc/samba/smbpasswd since it has a uid 500 entry
Offline
yes, /dev/null has now my middle name as user and group. But, so farm, I do not expect propblems,
because the rights are rw-rw-rw-. So everbody has permission for reading and writing.
If I detect problems, I can ommit this user on the NAS, because he is being created only for testing
purposes on clients.
/etc/samba/smbpasswd has still root.root, respectivly 500.500.
Actually I do not use UID/GID 500 on clients, I always start with 501.
Other question to you:
/sys/crfs/web/S_DOWN and /sys/crfs/web/webs may have this chown command.
But for what is crfs standing for? Could it be cram filesystem? I am running ext2 in RAID1 mode.
Maybe it will not be effektiv for me.
Did you detect other strings or pathes which are suspect?
Offline
Yes crfs is cram file system. I believe this is where the root files (which are stored in volatile memory) are loaded in on every boot...
I did not detect any other strings or paths and I looked fairly extensively (but no guarantees I was exhaustive).
Offline
So, what is our conclusion - does it work or not?
Up to now I do not have problems with rights.
Thereof I would say - Yes!
CU - Joerg
Offline