Other comments on this question discuss elevating user permissions via
suid, sudo the setuid bit and so on.
There are good reasons to need to create files with owner/group that are
different from your own, they usually come up in system administration
situations.  Most common situation where access sharing come up can be
handled with the way linux group membership works and use of the setgid bit
on directories.

If "appuser" is a member of "othergroup" and the directory where the script
will write the file is setgid "othergroup" then when the script writes the
file it will have group "othergroup".  Usually this is sufficient.

Of course this assumes linux and other things sufficiently unix like.

On Sun, Jan 15, 2017 at 3:45 PM, <al...@myfastmail.com> wrote:

> I have an application that calls a perl script, feeding it input over
> STDIN.
>
> The perl script takes that input, processes it, and writes is as a change
> to an output file.
>
> I use Path::Tiny, and this works ok,
>
>         use Path::Tiny qw(path);
>
>         my $newdata = $@;
>         $newdata = (some processing);
>
>         my $file = path('/home/aj/out.txt');
>         my $data = $file->slurp_utf8;
>         $data =~ s/some label.*/${1} $newdata} ]/x;
>         $file->spew_utf8( $data );
>
> The app runs as
>
>         USER  = "appuser"
>         GROUP = "appgroup"
>
> and the perl-script's output file gets CHANGED to ownership by the SAME
> user & group, 'appuser'/'appgroup'.
>
> How do I get that output file written with owndership by some OTHER user,
> eg
>
>         USER  = "otheruser"
>         GROUP = "othergroup"
>
> ?
>
> AJ
>
> --
> To unsubscribe, e-mail: beginners-unsubscr...@perl.org
> For additional commands, e-mail: beginners-h...@perl.org
> http://learn.perl.org/
>
>
>

Reply via email to