From a1667ba3e2ac427cafdd1bccd0d92240343e06a7 Mon Sep 17 00:00:00 2001 From: Jarkko Hietaniemi Date: Wed, 5 Dec 2001 19:49:16 +0000 Subject: [PATCH] Admonish against assuming A^HUNIX fs/uid/gid semantics. p4raw-id: //depot/perl@13479 --- pod/perlport.pod | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/pod/perlport.pod b/pod/perlport.pod index 3b11a4f..34e9dab 100644 --- a/pod/perlport.pod +++ b/pod/perlport.pod @@ -267,6 +267,13 @@ S perl can emulate Unix filenames with C as path separator, or go native and use C<.> for path separator and C<:> to signal filesystems and disk names. +Don't assume UNIX filesystem access semantics: that read, write, +and execute are all the permissions there are, and even if they exist, +that their semantics (for example what do r, w, and x mean on +a directory) are the UNIX ones. The various UNIX/POSIX compatibility +layers usually try to make interfaces like chmod() work, but sometimes +there simply is no good mapping. + If all this is intimidating, have no (well, maybe only a little) fear. There are modules that can help. The File::Spec modules provide methods to do the Right Thing on whatever platform happens @@ -538,13 +545,31 @@ more efficient that the first. Most multi-user platforms provide basic levels of security, usually implemented at the filesystem level. Some, however, do -not--unfortunately. Thus the notion of user id, or "home" directory, +not-- unfortunately. Thus the notion of user id, or "home" directory, or even the state of being logged-in, may be unrecognizable on many platforms. If you write programs that are security-conscious, it is usually best to know what type of system you will be running under so that you can write code explicitly for that platform (or class of platforms). +Don't assume the UNIX filesystem access semantics: the operating +system or the filesystem may be using some ACL systems, which are +richer languages than the usual rwx. Even if the rwx exist, +their semantics might be different. + +(From security viewpoint testing for permissions before attempting to +do something is silly anyway: if one tries this, there is potential +for race conditions-- someone or something might change the +permissions between the permissions check and the actual operation. +Just try the operation.) + +Don't assume the UNIX user and group semantics: especially, don't +expect the C<$E> and C<$E> (or the E<$(> and E<$)) to work +for switching identities (or memberships). + +Don't assume set-uid and set-gid semantics. (And even if you do, +think twice: set-uid and set-gid are a known can of security worms.) + =head2 Style For those times when it is necessary to have platform-specific code, -- 2.7.4