The reason why your sudo-created directories are owned by root:root is because sudo literally lets you run commands as a different user, in this case as root (since you did not specify a different username).
Put developer1 into the group www-data, then make sure the directory you want this user to create files/directories in is owned by the group www-data and is writable by said group.
Now developer1 can create files and directories in there, because his group memberships let him do this.
But you'll then notice that these new directories/files are owned by developer1:developer1 (or, alternatively, developer1:users or something like that). To fix this, you can make developer1's primary group www-data, in which case everything he creates will be owned by the www-data group.
If your goal is to have this user create files elsewhere in a different group (e.g. users or developers), but create them as www-data in e.g. /var/www, well, that's one thing I've not yet figured out. So far, I've been stuck with one of two (well, three, really: the third is to just live with it) workarounds:
- Have the user(s) manually
chgrp files and directories when they are created. Can be done recursively and/or in a batch, so you can e.g. upload a huge number of files and then chgrp them all at once.
- Set up a cron job that runs every so often (e.g. every 5-10 minutes) and recursively
chgrps everything under your web root (or whatever it is you're trying to control) to www-data. Alternatively, you can use this cron job to chown -R www-data:www-data /var/www to ensure that the files/directories all belong to the www-data user as well as the www-data group.
I realize neither of these is ideal, although once a file is created it will retain its ownership no matter who edits it.
It will typically get logged /var/log/secure, and mail will be sent to root on the local system. You can control this behavior in your /etc/sudoers file. There are a suite of mail_* configuration options that determine when sudo sends out mail, and there are additional options that control how it logs to syslog.
Best Answer
My experience is that 'user' needs to log out and in again. Try the 'id' command to see if the system thinks that 'user' is in the wheel group or not.