From @leonerd

Created by @leonerd

Reliable error detection of setuid/setgid/setgroups operations is next to impossible.

At first glance

  $> = $new_uid;
  $> == $new_uid or die "Failed to setuid - $!";

appears to work, but this might give the wrong failure in $!, because the
getuid operation on the second line may have overwritten $!.

  $> = $new_uid; my $saved_errno = $!;
  $> == $new_uid or do { $! = $saved_errno; die "Failed to setuid - $!" };

is a slight improvement.

The groups list in $) is harder, because some OSes remove duplicates, or
rearrange values in the values in the list. This requires some sort of
set-comparison operation.

perldoc perlvar claims the caller can simply check the value of $! after the
operation to detect success or failure, but a sourcedive of the code suggests
this is not the case.

From mg.c​:

2791 (void)seteuid((Uid_t)PL_euid);

2878 (void)setegid((Gid_t)PL_egid);

2867 (void)setgroups(i, gary);

Here Perl is ignoring the success-or-failure result from the set*() calls, and
just hoping that errno is set or not. The user code can't infer that just
because $! is now 0, or not 0, that the call suceeded or failed.

-----

I'd suggest a tiny improvement; fixing those lines to something such as​:

  if(seteuid((Uid_t)PL_euid) != -1) errno = 0;

so that Perl now guarantees that if every operation succeeds, errno and hence
$! will definitely be zero. If it fails, the syscall will have set a non-zero
value there.

I can supply a patch if required

Flags:
    category=core
    severity=low

Site configuration information for perl 5.12.4:

Configured by Debian Project at Sun Oct  9 12:36:46 UTC 2011.

Summary of my perl5 (revision 5 version 12 subversion 4) configuration:
   
  Platform:
    osname=linux, osvers=2.6.32-5-amd64, archname=x86_64-linux-gnu-thread-multi
    uname='linux brahms 2.6.32-5-amd64 #1 smp mon oct 3 03:59:20 utc 2011 x86_64 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.12 -Darchlib=/usr/lib/perl/5.12 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.12.4 -Dsitearch=/usr/local/lib/perl/5.12.4 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.12.4 -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.6.1', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=, so=so, useshrplib=true, libperl=libperl.so.5.12.4
    gnulibc_version='2.13'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.12.4:
    /home/leo/lib/perl5/x86_64-linux-gnu-thread-multi
    /home/leo/lib/perl5
    /etc/perl
    /usr/local/lib/perl/5.12.4
    /usr/local/share/perl/5.12.4
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.12
    /usr/share/perl/5.12
    /usr/local/lib/site_perl
    .


Environment for perl 5.12.4:
    HOME=/home/leo
    LANG=en_GB.UTF-8
    LANGUAGE=en_GB:en
    LD_LIBRARY_PATH=/home/leo/lib
    LOGDIR (unset)
    PATH=/home/leo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
    PERL5LIB=/home/leo/lib/perl5
    PERL_BADLANG (unset)
    PERL_MB_OPT=install_base=~
    PERL_MM_OPT=INSTALL_BASE=~
    SHELL=/bin/bash

From @cpansprout

On Sat Nov 19 07​:42​:28 2011, leonerd@​leonerd.org.uk wrote​:

This is a bug report for perl from leonerd@​leonerd.org.uk,
generated with the help of perlbug 1.39 running under perl 5.12.4.

-----------------------------------------------------------------
[Please describe your issue here]

Reliable error detection of setuid/setgid/setgroups operations is next
to impossible.

At first glance

$> = $new_uid;
$> == $new_uid or die "Failed to setuid - $!";

appears to work, but this might give the wrong failure in $!, because
the
getuid operation on the second line may have overwritten $!.

$> = $new_uid; my $saved_errno = $!;
$> == $new_uid or do { $! = $saved_errno; die "Failed to setuid -
$!" };

is a slight improvement.

The groups list in $) is harder, because some OSes remove duplicates,
or
rearrange values in the values in the list. This requires some sort of
set-comparison operation.

perldoc perlvar claims the caller can simply check the value of $!
after the
operation to detect success or failure, but a sourcedive of the code
suggests
this is not the case.

From mg.c​:

2791 (void)seteuid((Uid_t)PL_euid);

2878 (void)setegid((Gid_t)PL_egid);

2867 (void)setgroups(i, gary);

Here Perl is ignoring the success-or-failure result from the set*()
calls, and
just hoping that errno is set or not. The user code can't infer that
just
because $! is now 0, or not 0, that the call suceeded or failed.

-----

I'd suggest a tiny improvement; fixing those lines to something such
as​:

if(seteuid((Uid_t)PL_euid) != -1) errno = 0;

so that Perl now guarantees that if every operation succeeds, errno
and hence
$! will definitely be zero. If it fails, the syscall will have set a
non-zero
value there.

I can supply a patch if required

Generally the rule is that $! is only reliable when one already knows
there is an error.

But that leads to twisted code, as you demonstrated, as $> is not a
function that returns an error code.

So, at least for special variables like this, I would be all for the
change you suggest.

--

Father Chrysostomos

The RT System itself - Status changed from 'new' to 'open'

From @doy

On Sat, Nov 19, 2011 at 10​:00​:43AM -0800, Father Chrysostomos via RT wrote​:

On Sat Nov 19 07​:42​:28 2011, leonerd@​leonerd.org.uk wrote​:

I'd suggest a tiny improvement; fixing those lines to something such
as​:

if(seteuid((Uid_t)PL_euid) != -1) errno = 0;

so that Perl now guarantees that if every operation succeeds, errno
and hence
$! will definitely be zero. If it fails, the syscall will have set a
non-zero
value there.

I can supply a patch if required

Generally the rule is that $! is only reliable when one already knows
there is an error.

But that leads to twisted code, as you demonstrated, as $> is not a
function that returns an error code.

So, at least for special variables like this, I would be all for the
change you suggest.

You know, with all of these issues, and considering almost the entire
point of these functions is dealing with security issues, do we really
want to keep maintaining this really weird interface for them? Wouldn't
a better option be to deprecate $</$(/$>/$) and just make sure the
appropriate functions are exposed properly via POSIX? I find it a bit
hard to believe that anyone is actually using these correctly in their
current state.

-doy

From @Leont

On Sun, Nov 20, 2011 at 1​:32 AM, Jesse Luehrs <doy@​tozt.net> wrote​:

You know, with all of these issues, and considering almost the entire
point of these functions is dealing with security issues, do we really
want to keep maintaining this really weird interface for them? Wouldn't
a better option be to deprecate $&lt;/$(/$>/$) and just make sure the
appropriate functions are exposed properly via POSIX? I find it a bit
hard to believe that anyone is actually using these correctly in their
current state.

Yeah, that would be my sentiment too. It's an ok interface for reading
the real and effective IDs, but there are too many issues with setting
them this way (even if being able to localize the effective UID is
actually a pretty neat trick).

Alternatively, I think it wouldn't be a bad idea if failure throws an
exception. If anything calls for it, this is it.

Leon

From @leonerd

On Sun, Nov 20, 2011 at 01​:37​:42AM +0100, Leon Timmermans wrote​:

On Sun, Nov 20, 2011 at 1​:32 AM, Jesse Luehrs <doy@​tozt.net> wrote​:

You know, with all of these issues, and considering almost the entire
point of these functions is dealing with security issues, do we really
want to keep maintaining this really weird interface for them? Wouldn't
a better option be to deprecate $&lt;/$(/$>/$) and just make sure the
appropriate functions are exposed properly via POSIX? I find it a bit
hard to believe that anyone is actually using these correctly in their
current state.

Yeah, that would be my sentiment too. It's an ok interface for reading
the real and effective IDs, but there are too many issues with setting
them this way (even if being able to localize the effective UID is
actually a pretty neat trick).

Alternatively, I think it wouldn't be a bad idea if failure throws an
exception. If anything calls for it, this is it.

I'd be happy to deprecate writing to them, in favour of using
POSIX​::setuid() et.al. In fact I've already started hacking in changes
to expose these as 1-or-undef functions. Exposing these for real out of
POSIX would be most useful.

Shall I add it to my list of pending POSIX stuff? (i.e. strptime)

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http​://www.leonerd.org.uk/

From @doy

On Sun, Nov 20, 2011 at 01​:37​:42AM +0100, Leon Timmermans wrote​:

On Sun, Nov 20, 2011 at 1​:32 AM, Jesse Luehrs <doy@​tozt.net> wrote​:

You know, with all of these issues, and considering almost the entire
point of these functions is dealing with security issues, do we really
want to keep maintaining this really weird interface for them? Wouldn't
a better option be to deprecate $&lt;/$(/$>/$) and just make sure the
appropriate functions are exposed properly via POSIX? I find it a bit
hard to believe that anyone is actually using these correctly in their
current state.

Yeah, that would be my sentiment too. It's an ok interface for reading
the real and effective IDs, but there are too many issues with setting
them this way (even if being able to localize the effective UID is
actually a pretty neat trick).

Localizing the effective UID is a neat trick in the same way that
auto-closing filehandles when they go out of scope is a neat trick -
it's really convenient when it works, but you lose all hope of error
checking, which makes it dangerous to use safely (and if you have to do
extra things in order to use it safely, you lose the entire benefit of
the "clever" interface over doing it explicitly).

Alternatively, I think it wouldn't be a bad idea if failure throws an
exception. If anything calls for it, this is it.

I'd like to see this start to become true in a lot more situations (as
part of enabling an in-core and non-broken version of autodie with 5.18,
perhaps?).

-doy

From @khwilliamson

On 11/21/2011 11​:13 AM, Paul LeoNerd Evans wrote​:

On Sun, Nov 20, 2011 at 01​:37​:42AM +0100, Leon Timmermans wrote​:

On Sun, Nov 20, 2011 at 1​:32 AM, Jesse Luehrs<doy@​tozt.net> wrote​:

You know, with all of these issues, and considering almost the entire
point of these functions is dealing with security issues, do we really
want to keep maintaining this really weird interface for them? Wouldn't
a better option be to deprecate $&lt;/$(/$>/$) and just make sure the
appropriate functions are exposed properly via POSIX? I find it a bit
hard to believe that anyone is actually using these correctly in their
current state.

Yeah, that would be my sentiment too. It's an ok interface for reading
the real and effective IDs, but there are too many issues with setting
them this way (even if being able to localize the effective UID is
actually a pretty neat trick).

Alternatively, I think it wouldn't be a bad idea if failure throws an
exception. If anything calls for it, this is it.

I'd be happy to deprecate writing to them, in favour of using
POSIX​::setuid() et.al. In fact I've already started hacking in changes
to expose these as 1-or-undef functions. Exposing these for real out of
POSIX would be most useful.

Shall I add it to my list of pending POSIX stuff? (i.e. strptime)

+1

From @Leont

On Mon, Nov 21, 2011 at 7​:13 PM, Paul LeoNerd Evans
<leonerd@​leonerd.org.uk> wrote​:

I'd be happy to deprecate writing to them, in favour of using
POSIX​::setuid() et.al. In fact I've already started hacking in changes
to expose these as 1-or-undef functions. Exposing these for real out of
POSIX would be most useful.

Shall I add it to my list of pending POSIX stuff? (i.e. strptime)

There are issues with setuid(2) (in particular, on SysV-like systems
such as Linux non-root SetUID programs can't permanently revoke their
permissions with it). There is no portable solution to this in POSIX.
See also the recent «What should assignment to $&lt; and $( do?»
discussion (http​://code.activestate.com/lists/perl5-porters/170385/)
for some background information.

seteuid(2) and setegid(2) are both portable and sane, I'd love to have
them in POSIX, but anything else is at most one of those two. I'm not
sure there's an appropriate solution for the rest.

Leon

From zefram@fysh.org

Paul LeoNerd Evans wrote​:

I'd be happy to deprecate writing to them, in favour of using
POSIX​::setuid() et.al.

We need a module that collects all the Unix set*id functions, including
the non-POSIX ones such as setresuid and setfsuid.

-zefram

From @Leont

On Mon, Nov 21, 2011 at 8​:27 PM, Zefram <zefram@​fysh.org> wrote​:

We need a module that collects all the Unix set*id functions, including
the non-POSIX ones such as setresuid and setfsuid.

There is a good module on CPAN for [gs]etres[ug]id, and there's no
reason why anyone on a modern Linux would want to use setfsuid, so I
think that's covered.

Leon

From @leonerd

On Mon, Nov 21, 2011 at 07​:27​:21PM +0000, Zefram wrote​:

Paul LeoNerd Evans wrote​:

I'd be happy to deprecate writing to them, in favour of using
POSIX​::setuid() et.al.

We need a module that collects all the Unix set*id functions, including
the non-POSIX ones such as setresuid and setfsuid.

I was pondering hacking up a POSIX​::setuid or somesuch, that wrapped all
the various ID changing functions.

Though is there any reason why we shouldn't just pop those in the main
POSIX.{xs,pm} itself?

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http​://www.leonerd.org.uk/

From zefram@fysh.org

Paul LeoNerd Evans wrote​:

Though is there any reason why we shouldn't just pop those in the main
POSIX.{xs,pm} itself?

Yeah, the better ones aren't part of the POSIX standard.

-zefram

From @Leont

On Sun, Nov 20, 2011 at 1​:37 AM, Leon Timmermans <fawaka@​gmail.com> wrote​:

Alternatively, I think it wouldn't be a bad idea if failure throws an
exception. If anything calls for it, this is it.

I implemented this as a CPAN module, autodie​::variables just hit CPAN.
I have to admit, patching magic vtables on special variables was a
rather dirty hack.

Leon

From @rjbs

So some of the options​:

1. deprecate assigning to these vars, giving a long deprecation period (2yr) to let the
deprecation warnings hit people using vendorperls; after that period, assigning to $<,etc. is
fatal

2. continue to allow assignment to $<,etc., but make failures fatal

3. leave things as they are, but document the acrobatics that are required to try for sane error
handling

Also mentioned​: #2, but fatal only under some pragma like autodie or a feature.

My tentative favorite is #2. A grep of CPAN finds people using assignment to these vars, but
not checking that things work. Programs that are working should keep working. Programs
that are silently "working" should admit their sins. I predict that often these programs will be
run in contexts where warnings will be invisible.

Documentation should also be updated to explain why users should look at using something
else instead, too.

--
rjbs

From [Unknown Contact. See original ticket]

So some of the options​:

1. deprecate assigning to these vars, giving a long deprecation period (2yr) to let the
deprecation warnings hit people using vendorperls; after that period, assigning to $<,etc. is
fatal

2. continue to allow assignment to $<,etc., but make failures fatal

3. leave things as they are, but document the acrobatics that are required to try for sane error
handling

Also mentioned​: #2, but fatal only under some pragma like autodie or a feature.

My tentative favorite is #2. A grep of CPAN finds people using assignment to these vars, but
not checking that things work. Programs that are working should keep working. Programs
that are silently "working" should admit their sins. I predict that often these programs will be
run in contexts where warnings will be invisible.

Documentation should also be updated to explain why users should look at using something
else instead, too.

--
rjbs

From @Tux

On Thu, 24 Jan 2013 07​:09​:15 -0800, "Ricardo SIGNES via RT"
<perlbug-comment@​perl.org> wrote​:

So some of the options​:

1. deprecate assigning to these vars, giving a long deprecation period (2yr) to let the
deprecation warnings hit people using vendorperls; after that period, assigning to $<,etc. is
fatal

2. continue to allow assignment to $<,etc., but make failures fatal

3. leave things as they are, but document the acrobatics that are required to try for sane error
handling

Also mentioned​: #2, but fatal only under some pragma like autodie or a feature.

My tentative favorite is #2. A grep of CPAN finds people using assignment to these vars, but
not checking that things work. Programs that are working should keep working. Programs
that are silently "working" should admit their sins. I predict that often these programs will be
run in contexts where warnings will be invisible.

I've just user assigning to $&lt; and $&gt; last week to "fix" a serious
problem in a printer driver on Unix and Linux.

As it works, I think I fall under #2, but my initial reaction was #2
only fatal under autodie or similar.

Documentation should also be updated to explain why users should look at using something
else instead, too.

Yeah, esp when the shit hits the fan, it would be swell to see what to
use instead

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

From @ap

* Ricardo SIGNES via RT <perlbug-comment@​perl.org> [2013-01-24 16​:10]​:

So some of the options​:

1. deprecate assigning to these vars, giving a long deprecation
period (2yr) to let the deprecation warnings hit people using
vendorperls; after that period, assigning to $<,etc. is fatal

2. continue to allow assignment to $<,etc., but make failures fatal

3. leave things as they are, but document the acrobatics that are
required to try for sane error handling

Also mentioned​: #2, but fatal only under some pragma like autodie or a feature.

4. All of the above? :-)

I think assigning to these variables doesn’t make sense as an interface.
It might be good for it to go away in the very long run. So how about
a really long deprecation cycle for these, along the lines of​:

Year 1​: document alternatives; announce intentions in perldelta
Year 2​: warn on failure
Year 3​: die on failure
Year 4​: also warn on assignment
Year 5​: die on assignment

Programs that are working should keep working. Programs that are
silently "working" should admit their sins. I predict that often
these programs will be run in contexts where warnings will be
invisible.

Those all seem so to me as well. I am not convinced that what I proposed
above is actually a good idea. (I *am* convinced however that assignment
to these variables is a surprisingly pernicious interface, so I put it
forth anyway.)

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From @rjbs

This topic seemed likely to go somewhere less than a year ago, but seems now to have stalled.

Is there interest out there in figuring out the way forward?

--
rjbs

From @leonerd

On Sun, 25 Aug 2013 20​:14​:24 -0700
"Ricardo SIGNES via RT" <perlbug-followup@​perl.org> wrote​:

Is there interest out there in figuring out the way forward?

I'd be fairly interested in having some more reliable mechanism, yes. I
have no real preference for the existing variables as they are or
whatever; entirely new (regular) functions in a module would be fine
with me.

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http​://www.leonerd.org.uk/

From zefram@fysh.org

Ricardo SIGNES wrote​:

So some of the options​:

1. deprecate assigning to these vars, giving a long deprecation period
(2yr) to let the deprecation warnings hit people using vendorperls;
after that period, assigning to $<,etc. is fatal

I'd like to see us deprecate writing to $< et al. Interestingly,
and fairly unsurprisingly, making writing to them fatal doesn't cause
any failures in the core test suite, which implies that the moderately
tricky porting code around ID-swapping syscalls is all going untested.
Quite apart from the error-prone usage, this maintenance issue is a good
reason to punt this job to a module for which this is the raison d'etre.

Of course, we need to have such a module that we can confidently point
users towards. Unix​::SavedIDs (with bonus Unix​::SetUser in the distro)
looks somewhat like it could become that module, but it isn't there yet.
(I suspect that this is the module that LeonT was referring to as a "good
module on CPAN for [gs]etres[ug]id".) Its test suite is broken on current
Perls due to the removal of POSIX​::tmpnam(). It's also a problem that
it's specifically about setresuid(), which isn't available on all Unices
that have saved IDs, let alone on all Unices. Unix​::SetUser probably
needs to be split from Unix​::SavedIDs, because its concept doesn't depend
on having saved IDs. So there's porting work to be done here.

-zefram

From @Leont

On Mon, Dec 11, 2017 at 7​:24 AM, Zefram <zefram@​fysh.org> wrote​:

Ricardo SIGNES wrote​:

So some of the options​:

1. deprecate assigning to these vars, giving a long deprecation period
(2yr) to let the deprecation warnings hit people using vendorperls;
after that period, assigning to $<,etc. is fatal

I'd like to see us deprecate writing to $< et al.

I disagree with my past self here. I believe that getting rid of this will
break far more working code than it will "fix".

This functionality is usually used by scripts that have root privileges,
and hence pretty-much can't fail unless you're doing something silly. And
even outside of that (for example in a set-uid program) something like
«local $&gt; = $&lt;;» will essentially always succeed.

What would make more sense to me is to not let failures be silent. They
should either warn or die (as in autodie​::variables). That way we wouldn't
break working code but still handle error conditions better.

We should definitely fix our terrible documentation for these variables to
actually describe how to use them sensibly though.

Interestingly,
and fairly unsurprisingly, making writing to them fatal doesn't cause
any failures in the core test suite, which implies that the moderately
tricky porting code around ID-swapping syscalls is all going untested.
Quite apart from the error-prone usage, this maintenance issue is a good
reason to punt this job to a module for which this is the raison d'etre.

It can't really be tested because anything interesting requires root
permissions (and possibly more), and that's an assumption we can't make in
our test suite.

Of course, we need to have such a module that we can confidently point
users towards. Unix​::SavedIDs (with bonus Unix​::SetUser in the distro)
looks somewhat like it could become that module, but it isn't there yet.
(I suspect that this is the module that LeonT was referring to as a "good
module on CPAN for [gs]etres[ug]id".) Its test suite is broken on current
Perls due to the removal of POSIX​::tmpnam(). It's also a problem that
it's specifically about setresuid(), which isn't available on all Unices
that have saved IDs, let alone on all Unices. Unix​::SetUser probably
needs to be split from Unix​::SavedIDs, because its concept doesn't depend
on having saved IDs. So there's porting work to be done here.

Unix​::SavedIDs or Perm​::Uuid are excellent suggestions for in the docs, but
they only work on 3 platforms (Linux, FreeBSD and OpenBSD). That's not
enough for a true $> replacement.

Leon

From @cpansprout

On Tue, 12 Dec 2017 17​:26​:08 -0800, LeonT wrote​:

Perm​::Uuid

Where can I find this module? I don’t see it on CPAN.

--

Father Chrysostomos

From @Grinnz

On Tue, Dec 12, 2017 at 8​:25 PM, Leon Timmermans <fawaka@​gmail.com> wrote​:

We should definitely fix our terrible documentation for these variables to
actually describe how to use them sensibly though.

That would be really nice. I usually resort to using the equivalent
functions in POSIX.pm because it's easier to tell how they work. (Not to
mention that $( and $) are really weird, and reference setgroups() which
isn't in POSIX.pm.)
-Dan

From @Leont

On Wed, Dec 13, 2017 at 2​:58 AM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Tue, 12 Dec 2017 17​:26​:08 -0800, LeonT wrote​:

Perm​::Uuid

Where can I find this module? I don’t see it on CPAN.

I misremembered, that should have been Proc​::UID

Leon