On Thu, Jun 13, 2019 at 06:11:03PM -0400, Gene Heskett wrote: > looks good, but the problem is, only gene=user 1000 has any rights to > follow that path, so this access must be done as gene, not the default > www-data:www-data, or even as the parent session of apache2..
So change the ownership/permissions on the content. To serve it up from a web server, you need to make it world-readable. This means that directories require the x bit, and files require the r bit, for the "other" (right-most characters in ls -l output, least significant bits in the octal mode). In other words, 711 or 755 on the directories, and 644 on the files. > Is there > an "as user=gene" command that can be used only for this stanza that I > can put in this stanza? root cannot go up this path to see anything, > neither can www-data. If root can't see the files, that means you're dealing with some kind of remote file system, like NFS? If so, you really need to state the full relevant details up front. If you need to change permissions on an NFS-mounted file system that you're serving up through a web server on the NFS client system, then you'll need to make the changes *on* the NFS server, or as the owner of the files on the NFS client. By the way, I recommend running the web server from the same box where the files reside if at all possible, just for efficiency and sanity. > Is this a place where making gene a member of group www-data would help? No. Longer answer: each process has its own UID, GID and list of supplementary groups. If the apache worker process that tries to read your content is running as UID www-data and GID www-data with no supplementary groups, then the *only* permissions that matter are the "other" permissions on the file (those always matter), or the "group" permissions if the *FILE* belongs to group www-data (sounds like this is not the case), or the "user" permissions if the *FILE* belongs to user www-data (definitely not the case). When you "add user gene to group www-data", this has absolutely zero effect on a process that is running as user www-data/group www-data. (Daemons are launched by lower-level system processes that do not give half a flip about what groups users are "in" in /etc/group.) The only effect that your group addition has is on *logins* made by the user named gene. Future login sessions for gene will have one more group added to their list of supplementary groups. Adding a user to a group has no effect on files that you own. Each file has one user-owner, one group-owner, one octal mode number declaring yes/no permissions for user/group/owner, and some ACL crap that I *really* am not going to get into here. Suffice to say, "adding a user to a group" is not a thing that file systems or the files in them care about. Adding a user to a group has no effect on the privileges of daemons that are started by your init system. It *does* appear to affect the group membership of your at jobs, though. I didn't test cron, and of course neither cron(8) nor crontab(1) tells me whether it affects cron jobs, because why would they mention something important like the privileges of your running jobs....
