mkdir in Perl 5.8.8 Fails to Set the Sticky Bit on FreeBSD 7.1 #12082

p5pRT · 2012-05-04T23:54:07Z

Migrated from rt.perl.org#112760 (status was 'open')

Searchable as RT112760$

p5pRT · 2012-05-04T23:54:07Z

From steve.siano@yahoo.com

This is a bug report for perl from steve.siano@yahoo.com,
generated with the help of perlbug 1.35 running under perl v5.8.8.

The following does not set the sticky bit on FreeBSD, but it works on Linux:

perl -e "umask 0000; mkdir('foo', 01777);"

This behavior was observed on local disk and over NFS.

However, chmod does set the sticky bit on FreeBSD and Linux:

perl -e "umask 0000; chmod(01777, 'foo');"

Flags:
category=core
severity=medium

Site configuration information for perl v5.8.8:

Configured by fai at Thu Feb 5 00:58:00 UTC 2009.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=freebsd, osvers=7.1-release, archname=i386-freebsd-64int
uname='freebsd tinderbox.host 7.1-release freebsd 7.1-release #0: wed feb 4 16:57:47 pst 2009 root@tinderbox.host:usrsrcsysmagickernelpath i386 '
config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.8/mach -Dprivlib=/usr/local/lib/perl5/5.8.8 -Dman3dir=/usr/local/lib/perl5/5.8.8/perl/man/man3 -Dman1dir=/usr/local/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.8/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.8 -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/5.8.8/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Duseshrplib -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.8/BSDPAN" -Doptimize=-O2 -fno-strict-aliasing -pipe -Dd_dosuid=define -Ui_gdbm -Dusethreads=n -Dusemymalloc=y -Duse64bitint'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=y, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.8/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include',
optimize='-O2 -fno-strict-aliasing -pipe',
cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.8/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include'
ccversion='', gccversion='4.2.1 20070719 [FreeBSD]', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lm -lcrypt -lutil
perllibs=-lm -lcrypt -lutil
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/local/lib/perl5/5.8.8/mach/CORE'
cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
defined-or

@INC for perl v5.8.8:
/usr/local/lib/perl5/5.8.8/BSDPAN
/usr/local/lib/perl5/site_perl/5.8.8/mach
/usr/local/lib/perl5/site_perl/5.8.8
/usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/5.8.8/mach
/usr/local/lib/perl5/5.8.8
.

Environment for perl v5.8.8:
HOME=/homes/dc-builder
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/volume/buildtools/bin:/volume/fwtools/ccache/2.4-20100202-jnpr/bin:/volume/fwtools/tkcvs/current/bin:/homes/dc-builder/bin/bless:/homes/ssiano/bin/fx:/homes/ssiano/bin/git-1.7.9.FreeBSD.7.1/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/homes/dc-builder/bin
PERL_BADLANG (unset)
SHELL=/bin/bash

p5pRT · 2012-05-07T23:38:23Z

From @tonycoz

On Fri, May 04, 2012 at 04:54:07PM -0700, steve.siano@yahoo.com (via RT) wrote:

# New Ticket Created by steve.siano@yahoo.com
# Please include the string: [perl #112760]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=112760 >

This is a bug report for perl from steve.siano@yahoo.com,
generated with the help of perlbug 1.35 running under perl v5.8.8.

The following does not set the sticky bit on FreeBSD, but it works on Linux:
perl \-e "umask 0000; mkdir$'foo'\, 01777$;"
This behavior was observed on local disk and over NFS.

However, chmod does set the sticky bit on FreeBSD and Linux:
perl \-e "umask 0000; chmod$01777\, 'foo'$;"

perl 5.8.8 is no longer supported.

From man 8 sticky on FreeBSD 8.2:

BUGS
Neither open(2) nor mkdir(2) will create a file with the sticky bit set.

This isn't a perl bug, I'm not sure it's worthwhile working around
this limitation on BSDs.

mkdir -m 01775 foo

on FreeBSD does set the sticky bit, but it also ignores umask.

Tony

p5pRT · 2012-05-07T23:38:24Z

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

p5pRT · 2012-05-08T09:34:04Z

From @bingos

On Tue, May 08, 2012 at 09:37:50AM +1000, Tony Cook wrote:

On Fri, May 04, 2012 at 04:54:07PM -0700, steve.siano@yahoo.com (via RT) wrote:
# New Ticket Created by steve.siano@yahoo.com
# Please include the string: [perl #112760]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=112760 >

This is a bug report for perl from steve.siano@yahoo.com,
generated with the help of perlbug 1.35 running under perl v5.8.8.

The following does not set the sticky bit on FreeBSD, but it works on Linux:
perl \-e "umask 0000; mkdir$'foo'\, 01777$;"
This behavior was observed on local disk and over NFS.

However, chmod does set the sticky bit on FreeBSD and Linux:
perl \-e "umask 0000; chmod$01777\, 'foo'$;"
perl 5.8.8 is no longer supported.

From man 8 sticky on FreeBSD 8.2:

BUGS
Neither open(2) nor mkdir(2) will create a file with the sticky bit set.

This isn't a perl bug, I'm not sure it's worthwhile working around
this limitation on BSDs.

mkdir -m 01775 foo

on FreeBSD does set the sticky bit, but it also ignores umask.

I confirmed this on FreeBSD 7.4 with v5.8.9 and v5.14.0

Also behaves the same with v5.14.2 on FreeBSD 8.3 and 9.0

It also does on NetBSD 3.1 and 5.1.2

where man sticky says the same as on FreeBSD

And the same on OpenBSD 5.1 which again says the same bug
in man sticky.

I haven't checked DragonflyBSD nor MirBSD, but the docs for
DragonflyBSD suggest it is the same:

http://leaf.dragonflybsd.org/cgi/web-man?command=sticky&section=ANY

Cheers,

--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk

p5pRT · 2012-05-10T08:25:50Z

From steve.siano@yahoo.com

Thanks Tony for tracking down the root cause and thanks Chris for confirming it.

Since it is a BSD bug and not a Perl bug, I've updated my code accordingly:

if (mkdir($dir, $mode)) {
chomp(my $OS = `uname`);

if ($OS eq 'FreeBSD' && $mode & 01000) {
if (chmod($mode, $dir)) {

Sincerely,

Steve

----- Original Message -----
From: Kidney Bingos via RT <perlbug-followup@perl.org>
To: steve.siano@yahoo.com
Cc:
Sent: Tuesday, May 8, 2012 2:34 AM
Subject: Re: [perl #112760] mkdir in Perl 5.8.8 Fails to Set the Sticky Bit on FreeBSD 7.1

On Tue, May 08, 2012 at 09:37:50AM +1000, Tony Cook wrote:

On Fri, May 04, 2012 at 04:54:07PM -0700, steve.siano@yahoo.com (via RT) wrote:

# New Ticket Created by steve.siano@yahoo.com
# Please include the string: [perl #112760]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=112760 >

This is a bug report for perl from steve.siano@yahoo.com,
generated with the help of perlbug 1.35 running under perl v5.8.8.

The following does not set the sticky bit on FreeBSD, but it works on Linux:

perl -e "umask 0000; mkdir('foo', 01777);"

This behavior was observed on local disk and over NFS.

However, chmod does set the sticky bit on FreeBSD and Linux:

perl -e "umask 0000; chmod(01777, 'foo');"

perl 5.8.8 is no longer supported.

From man 8 sticky on FreeBSD 8.2:

BUGS
Neither open(2) nor mkdir(2) will create a file with the sticky bit set.

This isn't a perl bug, I'm not sure it's worthwhile working around
this limitation on BSDs.

mkdir -m 01775 foo

on FreeBSD does set the sticky bit, but it also ignores umask.

I confirmed this on FreeBSD 7.4 with v5.8.9 and v5.14.0

Also behaves the same with v5.14.2 on FreeBSD 8.3 and 9.0

It also does on NetBSD 3.1 and 5.1.2

where man sticky says the same as on FreeBSD

And the same on OpenBSD 5.1 which again says the same bug
in man sticky.

I haven't checked DragonflyBSD nor MirBSD, but the docs for
DragonflyBSD suggest it is the same:

http://leaf.dragonflybsd.org/cgi/web-man?command=sticky§ion=ANY

Cheers,

--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk

p5pRT · 2012-05-10T08:38:03Z

From @nwc10

On Tue, May 08, 2012 at 11:12:39AM -0700, Steve Siano wrote:

Thanks Tony for tracking down the root cause and thanks Chris for confirming it.

Since it is a BSD bug and not a Perl bug, I've updated my code accordingly:

if (mkdir($dir, $mode)) {
chomp(my $OS = `uname`);

if ($OS eq 'FreeBSD' && $mode & 01000) {
if (chmod($mode, $dir)) {

You might want to use $^O instead of `uname`, as it saves some work.
(Although it's 'freebsd', not 'FreeBSD' in $^O)

Nicholas Clark

p5pRT · 2012-05-10T15:46:53Z

From @ikegami

On Thu, May 10, 2012 at 4:37 AM, Nicholas Clark <nick@ccl4.org> wrote:

On Tue, May 08, 2012 at 11:12:39AM -0700, Steve Siano wrote:
Thanks Tony for tracking down the root cause and thanks Chris for
confirming it.

Since it is a BSD bug and not a Perl bug, I've updated my code
accordingly:

if (mkdir($dir, $mode)) {
chomp(my $OS = `uname`);
if $$OS eq 'FreeBSD' && $mode & 01000$ \{
    if $chmod\($mode\, $dir$\) \{
You might want to use $^O instead of `uname`, as it saves some work.
(Although it's 'freebsd', not 'FreeBSD' in $^O)

Nicholas Clark

I would simply avoid both.

if (mkdir($dir, $mode)) {
if ($mode & 01000) {
if (chmod($mode, $dir)) {

p5pRT · 2012-05-12T07:18:14Z

From @ap

* Tony Cook <tony@develop-help.com> [2012-05-08 01:40]:

This isn't a perl bug, I'm not sure it's worthwhile working around
this limitation on BSDs.

To me it would seem that it is. Dealing with this limitation in Perl
code requires monkey code to be added to every user program, and for it
to get added requires toes getting stubbed on this bug first. Working
around it at the interpreter level would allow user code to pretend that
all is right in the world.

At the perl level it can be fixed with an #ifdef protecting a chmod
guarded by a bit check. So the workaround is extremely cheap and even
then incurs a penalty only for those who need it; and it can easily be
dropped if and when FreeBSD is ever fixed, but at the same time breaks
nothing if it isn’t removed promptly – so maintenance burden is minimal.

There seems to be essentially zero downside to adding the workaround.

At the same time I can’t see any upside in not adding it and thereby
pushing the complexity out into Perl programs. Did I miss any benefit
here? Does what I missed outweigh the above benefits of doing it at the
interpreter level?

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

p5pRT · 2012-05-12T09:24:07Z

From @bingos

On Thu, May 10, 2012 at 09:37:21AM +0100, Nicholas Clark wrote:

On Tue, May 08, 2012 at 11:12:39AM -0700, Steve Siano wrote:

Thanks?Tony?for tracking down the root cause and thanks?Chris?for confirming it.

Since it is a BSD bug and not a Perl bug, I've updated my code accordingly:

if (mkdir($dir, $mode)) {
? ? chomp(my $OS = `uname`);

? ? if ($OS eq 'FreeBSD' && $mode & 01000) {
? ? ? ? if (chmod($mode, $dir)) {

You might want to use $^O instead of `uname`, as it saves some work.
(Although it's 'freebsd', not 'FreeBSD' in $^O)

Confirmed it on DragonflyBSD 3.0.2 now as well.

--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk

p5pRT · 2013-09-18T23:33:44Z

From @jkeenan

On Sat May 12 00:18:14 2012, aristotle wrote:

* Tony Cook <tony@develop-help.com> [2012-05-08 01:40]:

This isn't a perl bug, I'm not sure it's worthwhile working around
this limitation on BSDs.

To me it would seem that it is. Dealing with this limitation in Perl
code requires monkey code to be added to every user program, and for it
to get added requires toes getting stubbed on this bug first. Working
around it at the interpreter level would allow user code to pretend that
all is right in the world.

At the perl level it can be fixed with an #ifdef protecting a chmod
guarded by a bit check. So the workaround is extremely cheap and even
then incurs a penalty only for those who need it; and it can easily be
dropped if and when FreeBSD is ever fixed, but at the same time breaks
nothing if it isn’t removed promptly – so maintenance burden is minimal.

There seems to be essentially zero downside to adding the workaround.

At the same time I can’t see any upside in not adding it and thereby
pushing the complexity out into Perl programs. Did I miss any benefit
here? Does what I missed outweigh the above benefits of doing it at the
interpreter level?

Regards,

Tony, Aristotle:

Are there outstanding issues in this ticket that need addressing?

Thank you very much.
Jim Keenan

p5pRT · 2013-09-22T13:08:09Z

From @ap

* James E Keenan via RT <perlbug-followup@perl.org> [2013-09-19 01:35]:

Are there outstanding issues in this ticket that need addressing?

Yes: the original report. I am still of the opinion that a workaround
should be added. In the meantime I can also report that the same issue
afflicts Darwin (unsurprisingly).

p5pRT · 2013-09-22T15:04:36Z

From @Leont

On Sat, May 12, 2012 at 9:17 AM, Aristotle Pagaltzis <pagaltzis@gmx.de>wrote:

To me it would seem that it is. Dealing with this limitation in Perl
code requires monkey code to be added to every user program, and for it
to get added requires toes getting stubbed on this bug first. Working
around it at the interpreter level would allow user code to pretend that
all is right in the world.

To quote POSIX: "When bits in *mode* other than the file permission bits
are set, the meaning of these additional bits is implementation-defined."
So the BSDs are entirely conformant even if they desire other (equally
conformant) semantics. This is not really a bug.

At the perl level it can be fixed with an #ifdef protecting a chmod
guarded by a bit check. So the workaround is extremely cheap and even
then incurs a penalty only for those who need it; and it can easily be
dropped if and when FreeBSD is ever fixed, but at the same time breaks
nothing if it isn’t removed promptly – so maintenance burden is minimal.

There seems to be essentially zero downside to adding the workaround.

At the same time I can’t see any upside in not adding it and thereby
pushing the complexity out into Perl programs. Did I miss any benefit
here? Does what I missed outweigh the above benefits of doing it at the
interpreter level?

Sticky bits are uncommon enough that I think it's not worth the maintenence
costs.

Leon

p5pRT · 2013-09-22T18:18:43Z

From @ikegami

On Sun, Sep 22, 2013 at 11:03 AM, Leon Timmermans <fawaka@gmail.com> wrote:

To quote POSIX: "When bits in *mode* other than the file permission bits
are set, the meaning of these additional bits is implementation-defined."
So the BSDs are entirely conformant even if they desire other (equally
conformant) semantics. This is not really a bug.

Sticky bits are uncommon enough that I think it's not worth the
maintenence costs.

Just add that passage to mkdir's docs.

brookbot · 2022-06-21T22:16:56Z

I have the same problem on REHL8.
I believe this is documentation issue and that the Perl mkdir documentation could be updated to reflect that sticky bits may not be set on some platforms (or are never set). In particular at https://perldoc.perl.org/functions/mkdir is otherwise misleading.

In particular the sticky bit may or may not be set by the system mkdir() implementation. Fixes Perl#12082

In particular the sticky bit may or may not be set by the system mkdir() implementation. Fixes #12082

In particular the sticky bit may or may not be set by the system mkdir() implementation. Fixes Perl#12082

p5pRT added Severity Medium distro-freebsd type-core labels Oct 19, 2019

xenu removed the affects-5.8 label Nov 19, 2021

xenu removed the Severity Medium label Dec 15, 2021

tonycoz added a commit to tonycoz/perl5 that referenced this issue Jun 22, 2022

point out that non-permission bits for mkdir's mode are non-portable

bbff348

In particular the sticky bit may or may not be set by the system mkdir() implementation. Fixes Perl#12082

tonycoz mentioned this issue Jun 22, 2022

point out that non-permission bits for mkdir's mode are non-portable #19881

Merged

jkeenan closed this as completed in #19881 Jun 27, 2022

jkeenan pushed a commit that referenced this issue Jun 27, 2022

point out that non-permission bits for mkdir's mode are non-portable

c25af7d

In particular the sticky bit may or may not be set by the system mkdir() implementation. Fixes #12082

scottchiefbaker pushed a commit to scottchiefbaker/perl5 that referenced this issue Nov 3, 2022

point out that non-permission bits for mkdir's mode are non-portable

84913af

In particular the sticky bit may or may not be set by the system mkdir() implementation. Fixes Perl#12082

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

mkdir in Perl 5.8.8 Fails to Set the Sticky Bit on FreeBSD 7.1 #12082

mkdir in Perl 5.8.8 Fails to Set the Sticky Bit on FreeBSD 7.1 #12082

p5pRT commented May 4, 2012

p5pRT commented May 4, 2012

p5pRT commented May 7, 2012

p5pRT commented May 7, 2012

p5pRT commented May 8, 2012

p5pRT commented May 10, 2012

p5pRT commented May 10, 2012

p5pRT commented May 10, 2012

p5pRT commented May 12, 2012

p5pRT commented May 12, 2012

p5pRT commented Sep 18, 2013

p5pRT commented Sep 22, 2013

p5pRT commented Sep 22, 2013

p5pRT commented Sep 22, 2013

brookbot commented Jun 21, 2022

mkdir in Perl 5.8.8 Fails to Set the Sticky Bit on FreeBSD 7.1 #12082

mkdir in Perl 5.8.8 Fails to Set the Sticky Bit on FreeBSD 7.1 #12082

Comments

p5pRT commented May 4, 2012

p5pRT commented May 4, 2012

From steve.siano@yahoo.com

p5pRT commented May 7, 2012

From @tonycoz

p5pRT commented May 7, 2012

p5pRT commented May 8, 2012

From @bingos

-- Chris Williams aka BinGOs PGP ID 0x4658671F http​://www.gumbynet.org.uk

p5pRT commented May 10, 2012

From steve.siano@yahoo.com

-- Chris Williams aka BinGOs PGP ID 0x4658671F http​://www.gumbynet.org.uk

p5pRT commented May 10, 2012

From @nwc10

p5pRT commented May 10, 2012

From @ikegami

p5pRT commented May 12, 2012

From @ap

p5pRT commented May 12, 2012

From @bingos

-- Chris Williams aka BinGOs PGP ID 0x4658671F http​://www.gumbynet.org.uk

p5pRT commented Sep 18, 2013

From @jkeenan

p5pRT commented Sep 22, 2013

From @ap

p5pRT commented Sep 22, 2013

From @Leont

p5pRT commented Sep 22, 2013

From @ikegami

brookbot commented Jun 21, 2022

--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk

--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk

--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk