Re: web page problem
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....
Reply to: