Re: web page problem
On Friday 14 June 2019 08:46:51 am Greg Wooledge wrote:
> 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 in the end I copied the debs to a /home/gene/subdir made to catch
them, and changed the ownership of the subdir and contents to www-data,
then moved the whole thing to /var/www/html/gene/subdir, and added that
to the <a href "####",statement> and they can now be downloaded by
interested parties.
> 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.
Not NFS, its too wibbly, works only with the right phase of the moon and
your astrological period or some such. But an sshfs mount as me Just
Works. Because one of those isn't yet set for passwordless key file
access, I get asked for my password once, so this file has to be run by
hand:
#!/bin/bash
sshfs gene@shop:/ /sshnet/shop
sshfs gene@lathe:/ /sshnet/lathe
sshfs gene@GO704:/ /sshnet/GO704
sshfs pi@picnc:/ /sshnet/picnc
sshfs gene@rock64:/ /sshnet/rock64
I keep a bunch of that sort of stuff in ~/gene/bin, which is first in my
$PATH.
And I just got a lunch order from my missus. later.
>
> 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.
So it would appear now. With wheezy it was useally the fix.
> 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....
Good question, because I have another perms problem that is preventing
awfull from generating any data from looking at the apache2 logs, and
again it worked flawlessly on wheezy.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: