Re: Got that network problem solved, now a new one
I feel I've been warned off commenting here in case I come across as a
pontificating know-it-all who's insisting that you do everything in
"My Way". Well, if there are any opinions here about how things
*should* be done, they're nothing to do with me, but just taken from
the FHS (2015-03-19). It uses "must" in the same way that RFCs and
STDs do. Feel free to disagree with any of the observations I make.
On Wed 18 May 2016 at 19:10:10 (-0400), Gene Heskett wrote:
> On Wednesday 18 May 2016 17:42:59 Gene Heskett wrote:
>
> > Greetings all;
> >
> > I am, because my web page serves as a backup site for the os and some
> > tools for use with the now 30 year old trs-80 color computers, have a
> > script IP can run that pulls fresh copies of the sources for this code
> > using hg, then builds fresh copies and makes it all available on my
> > web page.
> >
> > Unfortunately that script, running as me, suddenly has no write
> > permissions to do what it does. This has been working for several
> > years.
> >
> > This is the script:
> > ============================
> > #!/bin/bash
> > # since I'm always forgetting who I am
> > if [ `whoami` != 'gene' ]; then
> > echo
> > echo "!!!!!!!!!!!!!!!!!! Warning !!!!!!!!!!!!!!!!!!!"
> > echo "this script needs to be run by user gene"
> > echo
> > echo
> > exit 1
> > fi
> > mv lwtools lwtools-$(date +%Y-%m-%d-%H-%M)
So, assuming you are and were in /opt, you must in the past have had write
permission as user gene to execute a mv.
> > hg clone http://lwtools.projects.l-w.ca/hg/ lwtools
> > cd lwtools
> > make
> > sudo make install
So presumably "gene" is not an alias for "root", ie $UID != 0 or you
wouldn't have bothered to sudo.
> > cd ..
> > echo
> > echo
> > echo "lwtools has been built, next is toolshed"
> > echo
> > echo
> > chown -R gene:www-data lwtools # make visible to the web
Someone pointed out that you could only do this as root.
I don't think this is true. As long as the files were owned by gene,
and gene is in both the old and new groups involved, then there's
no permission problem with changing the group ownership.
> > [ script repeats the same sort of stuff twice more ]
> > ==================================
> > and its now being denied at the first mv operation. /opt of course is
> > owned by root:root but that hasn't changed in 18 years of running
> > linux. This script has been running flawlessly about once a month
> > since July 2013 when I wrote it.
> >
> > So what was changed to prevent the common user from using /opt as
> > himself? cd'd to /opt, I can't even "touch ajunkfile". Grrrrrr. Me,
> > goes in search of my LART.
Well that would suggest you are used to having world write permission
in /opt; very unusual.
> > Better yet, how can I fix it? /opt permissions are 40755,
...which is "correct".
> and I'm
> > assuming a chmod 0777 as root would fix it temporarily, but thats one
> > hell of a kludge. I'd much rather find where the rules to this game
> > are and get them fixed.
Is it possible that you had the same idea three years ago?
> > Thanks all.
> >
> > Cheers, Gene Heskett
>
> I did the above, and fixed my script with line ending && so it would bail
> out at the error point,
I don't quite follow you here (the reference to &&), but I assume
you've just set /opt to world-writeable and then run the script.
> and got two of the 3 of them rebuilt, then
> switched /opt back to 0755 perms.
...which perhaps you didn't remember to do three years ago.
So what changed it back to 755? Well, there are less than obvious ways
like extracting files from a tar archive. That's caught people out in
the past.
It's highly unusual to have /opt world-writable. You, as admin, are
expected to make do with /opt/{bin,doc,include,info,lib,man}/ if
you create them. It's conceivable that an archive might contain,
say:
opt/
opt/lwtools/
opt/lwtools/...
with more conventional directory metadata.
(I couldn't follow the posts about bugs in the shell. What sort of bug
specifically are we, sorry, they, talking about?)
Cheers,
David.
Reply to: