[32794] in Perl-Users-Digest
Perl-Users Digest, Issue: 4058 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Oct 19 05:18:10 2013
Date: Sat, 19 Oct 2013 02:17:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 19 Oct 2013 Volume: 11 Number: 4058
Today's topics:
Re: using File::Spec to figure out that Path::Class is <rweikusat@mobileactivedefense.com>
Re: using File::Spec to figure out that Path::Class is <Cal@example.invalid>
Re: using File::Spec to figure out that Path::Class is <ben@morrow.me.uk>
Re: using File::Spec to figure out that Path::Class is <cal@example.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 18 Oct 2013 17:31:05 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: using File::Spec to figure out that Path::Class is really what I want
Message-Id: <87bo2mfsmu.fsf@sable.mobileactivedefense.com>
Cal Dershowitz <cal@example.invalid> writes:
> On 10/16/2013 05:39 AM, Rainer Weikusat wrote:
>
>> The traditional way to deal with permissions when creating a new
>> filesystem object would be to specify the maximally useful permission in
>> the creating call, ie
>>
>> mkdir('/tmp/aktenordner', 0777);
>>
>> and leave it to the user to use a umask value requesting that the bits
>> he doesn't like will be disabled. For the common umask value of 022
>> (disable other and group write permission), the call above would end up
>> creating a directory with 0755 permissions.
>
> Alright, I get now that umask IS a mask.
>
> $ umask
> 0022
> $ umask -S
> u=rwx,g=rx,o=rx
> $ mkdir rumpelstiltskin
> $ ls -l
> total 16
> drwxr-xr-x 2 fred automation 4096 Oct 17 15:27 rumpelstiltskin
> $
>
> These numbers would add to EEEE octal. Where's the room for the
> sticky bits?
'Octal' means 'base 8', hence, octal digits run from 0 - 7. Assuming all
bits were set, the numerical equivalent would be 0777. The next three
bits are used for 'special permission bits',
01000 - sticky bit
02000 - setgid bit
04000 - setuid bit
------------------------------
Date: Thu, 17 Oct 2013 00:42:53 -0700
From: Cal Dershowitz <Cal@example.invalid>
Subject: Re: using File::Spec to figure out that Path::Class is really what I want
Message-Id: <TNCdndEDSehjCcLPnZ2dnUVZ_v6dnZ2d@supernews.com>
On 10/16/2013 12:43 AM, Ben Morrow wrote:
>
> Quoth Cal Dershowitz <cal@example.invalid>:
>>
>> That said, the permission I want is 764, where a group member can write
>> but does not have the execute permissions that "I" do.
>
> It's almost never sensible to give someone read permission on a
> directory without also giving them search (execute) permission. (The
> reverse is often useful.) I don't think you understand what the
> 'execute' bits do on a directory: see your system documentation or a
> basic Unix tutorial. (On my system this is documented, rather briefly,
> in intro(2), and also in chmod(1).)
Again, I'd like to say that the reading made perfect sense to me. It
seemed relevant to maybe find out what permissions my OS is giving me.
My attempts to do that within Path::Class are below.
>
>> I don't look at
>> these permissions as any big deal, because it's all just me and whatever
>> automation means I can achieve.
>
> If this will eventually be used on a machine serving HTTP to the
> Internet then security is *always* a big deal. Get it right, or don't do
> it at all and leave it to people who can.
I don't want to imply that I'm glib about the topic but that there
aren't catastrophes to result from getting it wrong in the present case.
It seems that most of the reference is to the C of it, so I'm having
a hard time disambiguating.
>
>> I'm gonna use $rd(\d*) to mean references to directories.
>
> Why on Earth would you do that? Give your variables sensible names.
Reference to a directory and then a number. What's wrong with it?
>
>> One thing I think I don't get is "stringifying,"
>>
>> #my $rel = $rd3->relative; # Transform to relative path
>> #say "rel is $$rel";
>
> Stringifying means 'treating an object as though it were a string'. Try
>
> say "rel is $rel";
>
> without the extra scalar-deref.
>
> Ben
>
Ok, thanks Ben. This is output on a windows 8 laptop:
C:\scripts>perl kiwi6.pl chabot ceramic
-------------
a is scripts
-------------
srd3 is \scripts\ceramic\template_stuff
-------------
rel is ceramic\template_stuff
abs is C:\scripts\ceramic\template_stuff
my files are \scripts\chabot\template_stuff
file is \scripts\chabot\template_stuff\Config1.pm
... [lists all files]...
file is \scripts\chabot\template_stuff\rebus1.tmpl~
dir is \scripts\chabot\template_stuff
mode is 16895
uid is 0
dir is \scripts\chabot
mode is 16895
uid is 0
dir is \scripts\chabot\template_stuff\captions
mode is 16895
uid is 0
dir is \scripts\chabot\template_stuff\images
mode is 16895
uid is 0
C:\scripts>type kiwi6.pl
#!/usr/bin/perl -w
use strict;
use 5.010;
use Cwd;
use Path::Class;
use File::stat;
my ($from, $to) = @ARGV;
my $ts = "template_stuff";
my $images = "images";
my $captions = "captions";
my $current = cwd;
# choose good lexical variable for directory list: @a.
say "-------------";
my $rd2 = dir($current);
my @a = $rd2->dir_list();
say "a is @a";
say "-------------";
# define the paths within the target directory
my $rd3 = dir(@a,$to,$ts);
my $srd3 = $rd3->stringify;
say "srd3 is $srd3";
say "-------------";
my $rel = $rd3->relative; # Transform to relative path
say "rel is $rel";
my $abs = $rel->absolute; # Transform to absolute path
say "abs is $abs";
# define the paths within the source directory
my $rd4 = dir(@a,$from,$ts);
my $srd4 = $rd4->stringify;
my @files = <$srd4*>;
say "my files are @files";
while ($_ = $rd4->next) {
next unless -f $_;
say "file is $_";
}
while ($_ = $rd4->next) {
next unless -d $_;
say "dir is $_";
my $st = $_->stat();
my $mode = $st->mode();
say "mode is $mode";
my $uid = $st->uid();
say "uid is $uid";
}
C:\scripts>
Q1) Does either of the calls I made to File::stat methods say anything
relevant to the permissions of the directories?
Q2) Path::Class has its own mechanism for while'ing over a directory
which seems to work. Why does this not?
my $srd4 = $rd4->stringify;
my @files = <$srd4*>;
Thanks for your comment.
--
Cal
------------------------------
Date: Thu, 17 Oct 2013 11:03:17 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: using File::Spec to figure out that Path::Class is really what I want
Message-Id: <58p4ja-fgu1.ln1@anubis.morrow.me.uk>
Quoth Cal Dershowitz <Cal@example.invalid>:
>
[stat and chmod]
>
> Ok, thanks Ben. This is output on a windows 8 laptop:
Note that Unix permissions don't apply on Windows. Perl pretends that
stat and chmod work as they do on Unix, but the Windows permissions
system is really quite different.
> while ($_ = $rd4->next) {
> next unless -d $_;
> say "dir is $_";
> my $st = $_->stat();
> my $mode = $st->mode();
> say "mode is $mode";
> my $uid = $st->uid();
> say "uid is $uid";
> }
>
> Q1) Does either of the calls I made to File::stat methods say anything
> relevant to the permissions of the directories?
Yes, the ->mode member of the stat structure contains the permissions
bits. See perldoc -f stat for an example of using the S_ function from
Fcntl to decode it. I don't know what the uid member contains under
Windows, but I suspect it's useless.
> Q2) Path::Class has its own mechanism for while'ing over a directory
> which seems to work. Why does this not?
>
> my $srd4 = $rd4->stringify;
> my @files = <$srd4*>;
Probably because $srd4 does not end with a slash. I told you before: you
should construct a file path with a filename of "*", and then pass that
to glob. With Path::Class this would be
my @files = glob $rd4->file("*");
Ben
------------------------------
Date: Thu, 17 Oct 2013 15:44:20 -0700
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: using File::Spec to figure out that Path::Class is really what I want
Message-Id: <Fa-dnajK8Yrd9f3PnZ2dnUVZ_t2dnZ2d@supernews.com>
On 10/16/2013 05:39 AM, Rainer Weikusat wrote:
> The traditional way to deal with permissions when creating a new
> filesystem object would be to specify the maximally useful permission in
> the creating call, ie
>
> mkdir('/tmp/aktenordner', 0777);
>
> and leave it to the user to use a umask value requesting that the bits
> he doesn't like will be disabled. For the common umask value of 022
> (disable other and group write permission), the call above would end up
> creating a directory with 0755 permissions.
Alright, I get now that umask IS a mask.
$ umask
0022
$ umask -S
u=rwx,g=rx,o=rx
$ mkdir rumpelstiltskin
$ ls -l
total 16
drwxr-xr-x 2 fred automation 4096 Oct 17 15:27 rumpelstiltskin
$
These numbers would add to EEEE octal. Where's the room for the sticky
bits?
> If you wanted the permissions to be exactly what was given in the mkdir,
> you'd have to clear the umask first. It is usually sensible to use a
> code sequence a la
>
> my $omask;
>
> $omask = umask(0);
> mkdir('/tmp/aktendurcheinanderer', 0764);
> umask($omask);
>
> to avoid unintended interactions with code following the traditional
> convention.
>
> The umask can also be used to control the effective permissions of a
> filesystem object created by some system call which doesn't take an
> explicit permission argument but implicitly uses 0777. In this case, the
> umask can be set to the inverse of the desired permission set in order
> to create the directory entry with the desired permisson set. Eg,
>
> --------
> use Socket;
>
> my $sk;
>
> socket($sk, PF_UNIX, SOCK_DGRAM, 0);
> umask(~0660);
> bind($sk, pack_sockaddr_un('/tmp/strangers_no_trespass'));
> --------
>
> can be used to create a directory entry for a UNIX-domain socket which
> won't be world-writeable.
>
Ok, thx Rainer, it seems clear to me that I want to deal with this at
the shell level and make my directories inherit. The Windows side was
getting into the Icactl command, which I didn't want to get into any more.
--
Cal
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4058
***************************************
