There are basically two things to this:
1) permissions on the files and directory that already exist:
Alan's answer mostly covers this: create a special group to which you add all users that might need to write the files. Make sure that the directory where you are uploading is itself writable for that group: chmod 0775 path/to/the/directory. Any existing files will need chmod 0664.
The "magic" numbers are octal and stand for triplets: setuid, owner permissions, group permissions, world permissions. The setuid is no of interest for you, keep it 0. for the others the octal number (0-7) tells you the permissions: if the 0th bit is on, the file/directory is executable (for directory it means it can be entered), if 1st bit is on it is writeable, the 2nd bit is managing readability - e.g. 0754 would mean that owner has all permissions, group members can read and execute, and the rest of the world may only read it. You can write the same with mnemonics like this: chmod u=rwx,g=rx,o=r. See man chmod a Linux system for in depth explanation.
2) permissions on newly created files:
Look for umask setting in whatever does the uploading. This says with what permissions new files are created.Again see man umask on Linux/UNIX system, the idea is, that whatever bits you set in umask (the same notation as for chmod explained above) are excluded from the permissions on a newly created files - for example if you set your umask to 0023, your files will be created with all permissions for you, not writeable for your default group and not writeable neither executable by anybody else. It is usually bad idea to set the 0th bit here, since on directory creation it makes it non-executable which blocks entering the directory at all (for the set of users for which the bit is set, in the 0023 example for "anybody else").
In addition to this, it might be worth assigning default ACLs to the directory if the underlying filesystem supports them. That would allow finer grained access control (ACL stands for Access Control List, similar to the Windows one). See man setfacl for more information.
BIG FAT WARNING: It's not a good idea to make files world-writable! Keep the rights at the minimum that works.
It is just rm admin, assuming there is no alias for rm defined. You could do /bin/rm -i admin, if you are nervous - the -i option will explicitly ask rm: remove symbolic link 'admin'?.
Just make sure you don't use Tab which might get you a / after admin, (although you would still need -rf to make that cause problems)
Best Answer
Symlinks themselves have 777 because in Unix, file security is judged on a file/inode basis. If it's the same data they're operating on, it should have the same security conditions, regardless of the name you gave the system to open it.
Since permissions are set on the inode, it won't work with hard links even:
A symlink isn't an inode (which actually stores the data you're wanting to secure) ergo in the Unix model it complicates things by having two different sets of permissions for protecting the same data.
It sounds like this is an attempt to give different groups of people different levels of access rights to the same file. If that's the case you're actually supposed to use POSIX ACL's (via
setfaclandgetfacl) to give the files appropriate permissions on the target of the symlink.EDIT:
To elaborate on the direction you're probably wanting to go in, it's something like:
The above gives the
apacheuser (substitute with whatever user your apache/nginx/whatever is running as) read-only access to the target of the symlink, and givesgroupOfProgrammersread access to the directory the symlink is in (so thatgroupOfProgrammerscan get a complete directory listing there), but turns all permission bits off for the same target of the symlink.