You can't do this only with chmod. You can, however, make a new group and change the group ownership of the directory, add the user to that group and then give the group the permissions you want on the directory, so you can give privilege to only that group.
To create a group tomcat and add the user tomcat8 to it:
sudo groupadd tomcat && sudo adduser tomcat8 tomcat
You may also want to add yourself (and any other users who need read write access here) to the group with sudo adduser [username] tomcat
Now change the group ownership of the directory:
sudo chown :tomcat /usr/local/javaagent/appagent/ver2/logs/Tomcat1
Don't forget the colon - this is to change only the group ownership.
Now change permissions, for example, you add read and write permissions to the group like this:
sudo chmod g+rw /usr/local/javaagent/appagent/ver2/logs/Tomcat1
From your question I'm not sure what you want the other settings to be. I recommend reading man chmod and this guide to permissions to understand better what you are doing.
Directories need execute permissions to be entered and searchable, so you most likely want octal 775 (so all users can read and search but only group can write) or 770 (so only owner and group have any permissions - keeping the directory private)
Don't use -R as it's unlikely you want all files to have execute permission.
You probably do want to add the setgid bit though, so that files created here by all users inherit the same group ownership as the directory:
chmod g+s /usr/local/javaagent/appagent/ver2/logs/Tomcat1
Or using octal, in one step:
chmod 2775 /usr/local/javaagent/appagent/ver2/logs/Tomcat1
which gives these permissions:
drwxrwsr-x
(the s in that position is the setgid bit) or
chmod 2770 /usr/local/javaagent/appagent/ver2/logs/Tomcat1
which gives
drwxrws---
To check permissions and owners on the directory, use ls -ld:
ls -ld /usr/local/javaagent/appagent/ver2/logs/Tomcat1
Best Answer
This answer completely ignores the request in favour of addressing the how you contact the right people to make a feature request in an upstream project.
This request is already been asked and rejected. The behaviour is already possible through existing mechanisms (see the comments on your question).
For the best way to get something like that under the nose of somebody who makes the decisions, you need to find out where a package comes from. Start by tracking down the package for the command:
Then look at the
coreutilspackage details:Launchpad and Debian are red herrings here. They're very downstream. The project is a GNU one. The Homepage link is a good start here: http://gnu.org/software/coreutils
On there you'll find the various mailing lists you'll need to convince people on, as well as bug trackers (but I'm not sure how they'll take a feature request - check the rules first).