Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #8645
| From | dave.gma+news002@googlemail.com.invalid (Dave Gibson) |
|---|---|
| Newsgroups | uk.comp.os.linux, comp.os.linux.misc |
| Subject | Re: rsync: exclude all, then include only specified, wildcard problems.. |
| Date | 2013-06-29 01:30 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <kdm1aaxam2.ln2@perseus.wenlock-data.co.uk> (permalink) |
| References | <kpsi1n$37d$1@dont-email.me> <fmip9axqu1.ln2@perseus.wenlock-data.co.uk> <kqkclk$k80$1@dont-email.me> |
Cross-posted to 2 groups.
In comp.os.linux.misc, David
<david@55952163-3189045.bogus.domain.invalid> wrote:
> Dave Gibson wrote, on 2013-06-25:
>> In comp.os.linux.misc, David
>>> <david@55952163-3189045.bogus.domain.invalid> wrote:
>> Use id -u rather than testing $USER.
>
> Thanks for the tip, I didn't know about the 'id' command.
> I'm guessing that this might be because the $USER variable could be
> faked?
Yes.
>>> # chown the src files first
>>> # (so that the dest files will have the correct u+g ownership)
>>> echo 'chowning source files with required ownership for destination..'
>>> chown -R root:apache "$SRCROOT"
>>
>> Use newgrp to change root's primary group to apache, then run rsync
>> with --no-g.
>
> I wasn't aware of the 'newgrp' command either(!).
>
> I tried your revised script, but I think I have stumbled at this point.
Ah. You found that banana skin I dropped.
>
> Nothing gets synced when using newgrp, but does if I comment that out
> (ie, not over-riding(?) the existing root group permissions).
Humble pie from comp.os.linux.misc
(Message-ID: <omqp9axbq2.ln2@perseus.wenlock-data.co.uk>)
------------------------------------------------------------------------
Bugger. I was confusing sg with newgrp and getting them both wrong.
newgrp runs a shell so can't be used within the script and while sg
can run a command as a different group it accepts only a single argument
with -c so arguments with embedded spaces need special quoting which
pretty much puts you back to square one.
With newgrp:
newgrp apache
/path/to/script -commit
exit
With sg:
sg apache -c "/path/to/script -commit"
One possibility would be to use a wrapper script to run the main script
(which doesn't need to accept arguments with embedded spaces) with the
appropriate group.
#! /bin/sh -
mainscript=/path/to/script
if [ `id -u` -ne 0 ]; then
echo "$0: administrator privileges required." 1>&2
exit 1
fi
if [ ! -x "$mainscript" ]; then
echo "$0: missing script: $mainscript" 1>&2
exit 1
fi
if [ "`id -gn`" = apache ]; then
"$mainscript" "$@"
else
sg apache -c "$mainscript $*"
fi
------------------------------------------------------------------------
>
> The source part of the filesystem (where the files were checked out to)
> isn't readable by apache (I guess we'd need to make a new group
> (currently staff) and add apache and the developer users to it?),
> and similarly, the $DSTROOT of the destination (...../data/ isn't, for
> legitimate/essential reasons, writable by apache either (only certain
> folders within it).
As long as the user running the script is able to access the hierarchies
a change of primary group won't matter.
>
> It's not entirely clear from the manual what newgrp does exactly, but
> if it gives the user *only* the permissions that the apache group has
> (rather than *adding* (as it were?) to the existing permissions), then
> that might not work as a solution in this case.
Added.
Users are often members of several groups with one of those groups
being the "current" group ID. newgrp changes the current group ID but
the user remains a member of the other groups.
id -gn
id -Gn
>> #! /bin/sh -
>
> Is the "-" this?
>
> - Expands to the current option flags as specified upon invoca?
> tion, by the set builtin command, or those set by the shell
> itself (such as the -i option).
That's referring to the expansion of "$-"
$ echo "$-"
himBH
See the set builtin section:
- Signal the end of options, cause all remaining args to
be assigned to the positional parameters. The -x and -v
options are turned off. If there are no args, the posi-
tional parameters remain unchanged.
It's roughly equivalent to:
#! /bin/sh +vx -- "$@"
>> # DRYRUN is the rsync option for running in dryrun mode
>> DRYRUN="-n"
>> MODE='dryrun'
>>
>> synclist="
>> $SRCROOT/./webs/web1/php_includes
>> $SRCROOT/./webs/web1/php_snippets
>> $SRCROOT/./webs/web2/php
>> "
>
> I'm just idly curious why you have chosen to name some variables in
> upper case
Yanked from the original script.
> and some in lower case?
allcaps aversion disorder.
> Personal choice/preference, of
> course, but I would normally (not that I would claim to be a real
> shell expert) use upper case, having picked that up as a convention
> from somewhere..
I once spent FAR TOO LONG trying to figure out why /usr/bin/gzip would
compress itself whenever a particular script was run. It turned out
that in the script $GZIP was used to refer to a compressor:
GZIP=/usr/bin/gzip
then
"$GZIP" /path/to/tarball
It's a good idea in general -- edit one line to change the compressor
everywhere in the script.
However, gzip examines its environment and essentially treats $GZIP as
an extension to the command line. /usr/bin/gzip isn't a gzip option so
was taken as the name of a file to compress.
For extra annoyance, although GZIP wasn't exported in the script, it was
present in (and exported from) the script's parent's environment which
marked it for export within the script and thus visible to gzip.
>> # Restrict word splitting and disable globbing.
>> # There is one newline between the single quotes -- "IFS='<newline>'"
>> IFS='
>> '
>> set -f
>
> Ah, this is clearly what I needed to know to avoid tangling myself up
> with filenames and wildcards, etc..
>
> [Looks at manual..]
>
> Could you maybe explain what the reason is for setting IFS to
> <newline> *only* (rather than the default)?
When the shell expands an unquoted variable it splits the expansion
into individual fields ("words") delimited by any characters in $IFS.
Omitting the space and tab from $IFS allows fields to contain those
characters.
$ foo='how many
fields here'
$ printf '%s\n' $foo
how
many
fields
here
$ IFS='
'
$ printf '%s\n' $foo
how many
fields here
> ..and 'set -f' "[d]isable[s] pathname expansion", so that's what prevents
> wildcards being interpreted?
Yes. After word-splitting, each word is checked for wildcard characters,
if any are present the shell treats the word as a pattern to be replaced
with a list of matching filenames.
foo=*
echo $foo
>
>
>> [ -n "$dgrp" ] && newgrp "$dgrp"
It doesn't matter how many times I see it, that damn line still isn't
getting any less wrong.
>>
>> $cmd
Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
rsync: exclude all, then include only specified, wildcard problems.. David <david@55952163-3189045.bogus.domain.invalid> - 2013-06-19 15:17 +0000
Re: rsync: exclude all, then include only specified, wildcard problems.. Rikishi42 <skunkworks@rikishi42.net> - 2013-06-20 00:49 +0200
Re: rsync: exclude all, then include only specified, wildcard problems.. David <david@55952163-3189045.bogus.domain.invalid> - 2013-06-25 11:50 +0000
Re: rsync: exclude all, then include only specified, wildcard problems.. Rikishi42 <skunkworks@rikishi42.net> - 2013-06-26 01:59 +0200
Re: rsync: exclude all, then include only specified, wildcard problems.. Richard Kettlewell <rjk@greenend.org.uk> - 2013-06-20 10:16 +0100
Re: rsync: exclude all, then include only specified, wildcard problems.. The Natural Philosopher <tnp@invalid.invalid> - 2013-06-20 14:19 +0100
Re: rsync: exclude all, then include only specified, wildcard problems.. David <david@55952163-3189045.bogus.domain.invalid> - 2013-06-25 11:17 +0000
Re: rsync: exclude all, then include only specified, wildcard problems.. Chris Davies <chris-usenet@roaima.co.uk> - 2013-06-20 10:57 +0100
Re: rsync: exclude all, then include only specified, wildcard problems.. David <david@55952163-3189045.bogus.domain.invalid> - 2013-06-25 11:40 +0000
Re: rsync: exclude all, then include only specified, wildcard problems.. Chris Davies <chris-usenet@roaima.co.uk> - 2013-06-25 21:00 +0100
Re: rsync: exclude all, then include only specified, wildcard problems.. dave.gma+news002@googlemail.com.invalid (Dave Gibson) - 2013-06-20 18:37 +0100
Re: rsync: exclude all, then include only specified, wildcard problems.. David <david@55952163-3189045.bogus.domain.invalid> - 2013-06-25 14:00 +0000
Re: rsync: exclude all, then include only specified, wildcard problems.. Richard Kettlewell <rjk@greenend.org.uk> - 2013-06-25 15:24 +0100
Re: rsync: exclude all, then include only specified, wildcard problems.. dave.gma+news002@googlemail.com.invalid (Dave Gibson) - 2013-06-25 19:23 +0100
Re: rsync: exclude all, then include only specified, wildcard problems.. Chick Tower <c.tower@deadspam.com> - 2013-06-20 18:04 +0000
Re: rsync: exclude all, then include only specified, wildcard problems.. dave.gma+news002@googlemail.com.invalid (Dave Gibson) - 2013-06-25 23:37 +0100
Re: rsync: exclude all, then include only specified, wildcard problems.. dave.gma+news002@googlemail.com.invalid (Dave Gibson) - 2013-06-26 01:54 +0100
Re: rsync: exclude all, then include only specified, wildcard problems.. David <david@55952163-3189045.bogus.domain.invalid> - 2013-06-28 16:12 +0000
Re: rsync: exclude all, then include only specified, wildcard problems.. dave.gma+news002@googlemail.com.invalid (Dave Gibson) - 2013-06-29 01:30 +0100
Re: rsync: exclude all, then include only specified, wildcard problems.. Chris Davies <chris-usenet@roaima.co.uk> - 2013-07-01 09:51 +0100
csiph-web