|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| News | See also | Recommended Links | Mini-tutorial | Recommended Papers | Internals | Modification of ls to display ACLS |
| ACL Permissions for Directories | Perl interface | Random Findings | Humor | Etc |
|
|
Linux was "ACL-retarded" OS for quite a long time which caused a lot of grief for administrators who use to work with ACLs on other OSes (Solaris used to have an excellent ACL implementation for a decade or so). But the number of administrators who use ACL is very small and this deficiency actually matters much less that it looks on the first sight. The main "consumers" are organizations that extensively use SAMBA. Also this situation this recently changed. It is fully implemented in RHEL 5.2 and later for ext3 filesystem (and some other), as well as in Suse 10 SP2 and later. Previous situation when some utilities understood ACLs and some does not is corrected.
|
|
ACLs are additional sets of read/write/execute triplets (rwx) that can be added on to files, directories, devices, or any other file system objects on per user or per group basis.
ACL are separate from classic Unix permissions. As they were added as an afterthought, the integration is not perfect: they are not displayed by default by commands such as ls ( ls just indicates whether they are present or not).
While their popularity came from Windows and most often they are used by those who implement samba, in essence, ACL can be viewed as an extension of a Unix group mechanism (multiple groups, each with a separate permissions set can be assigned to a file). In this case the fact of assigning access to a particular user can be viewed as an assignment of the particular permission set to a group with just one member (trivial group).
As inability to assign files to multiple groups was a serious drawback of Unix from day one, and ACL provides the capabilities for enhancing Unix file security by enabling you to define file permissions for additional groups. For directories it also enables you to define default permissions.
It is important to understand that like regular permissions ACL behaves differently for files and directories (only directories have additional set of so called "default permissions").
| ACL behaves differently for files and directories (only directories have additional set of so called "default permissions"). For directories it enables to define default permissions. |
The Linux ACL facility is compliant with the POSIX 1003.6 specification. Interoperation with other platforms is limited: until RHEL 5.2 Linux has weak implementation with many utilities (for example tar) which were "ACL-blind". Linux implementation works with the NFS and samba. In case of NSF interoperability is limited both the NFS server and the client must be running Linux.
While ACL are file based they are essentially user-oriented: For each file you can define a list of additional users (pseudo-owners) and groups (pseudo-groups) that will have a certain level of access: read, write, or execute access permissions
ACLs grant "higher-level" access rights that have priority over regular file permissions.
Implementation is based on the concept of shadow inodes: when you create an ACL, the existing inode points to a newly allocated inode called a shadow inode. When a specific ACL entry is placed on the ACL list, the shadow inode contains a pointer to a data block containing the list of ACL entries. That permits utilities that does not understand ACLs work correctly with files that have ACLs set. In this case, for example when you are using gnu tar instead of Linux tar, they will strip all your ACL information.
Traditional Unix ls command is "ACL blind" and cannot display attributes, but you can use the ls -l command to see which files or directories have an ACL entry. If a file has an ACL entry, a plus (+) sign appears at the end of the permission field. There are several way to compensate for this deficiency
The classical user/group/everyone file permissions that the UNIX world has been used to the last 30 years, is pretty much an assumed. Nowadays, however, many UNIX implementations allow for granular file access control lists. Most UNIX administrator’s still avoid them because they are not as apparent to them when doing a file listing.
I decided to be different. I wrote a tool to enhance the standard “ls” command into displaying file ACL’s.
find $PWD -exec ls -ld {} \; | egrep '^.{10}\+'
There are two separate commands for working with ACLs:
getfacl permits reading ACLs for files and directoriessetfacl permits setting ACLs Running getfacl on a normal file provides mapping of regular permissions
to ACL world:
% cd /usr/tmp % touch foo % ls -l foo -rw-r--r-- 1 pbg staff 0 Jul 22 13:35 foo % getfacl foo # file: foo # owner: pbg # group: staff user::rw- group::r-- #effective:r-- mask:rwx other:r--
The user, group and other information is a straightforward
display of the permission bits for those fields.
It is also important to note that ACLs "stick" to a file during copy and rename operations that are performed using regular commands like cp and mv. To remove the ACL from a file use setfacl -d for each entry. When the last entry is removed, the "+" disappears from the ls listingy.
To set an ACL for a file, use the command setfacl:
% setfacl -m user:jeff:rw- foo % ls -l foo -rw-r--r--+ 1 pbg staff 0 Jul 22 13:52 foo % getfacl foo # file: foo # owner: pbg # group: staff user::rw- user:jeff:rw- #effective:r-- group::r-- #effective:r-- mask:r-- other:r--
The -m option tells setfacl that I want to modify the
ACLs for the file. You can specify only those attributes that you need to change.
It looks like man page statement "When using the -m option to modify a default ACL,
you must specify a complete default ACL (user, group, other, mask, and any additional
entries) the first time" is incorrect:
-m acl_entries
Adds one or more new ACL entries to the file, and/or modifies one or more existing ACL entries on the file. If an entry already exists for a specified uid or gid, the specified permissions will replace the current permissions. If an entry does not exist for the specified uid or gid, an entry will be created. When using the -m option to modify a default ACL, you must specify a complete default ACL (user, group, other, mask, and any additional entries) the first time.
Use the -s option to set the entire mode, but then you must type
in the user, group, and other access bits as well:
setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:jeff:rw- foo
To set general user, group, and other permissions, use the field::perms
identifier. To set ACLs for individual users and groups, use the field:uid
or gid:perms identifier.
But back to our previous example. Notice that the effective access for user Jeff is unchanged, he can still only read the file, not write to it. That's the result of the mask being applied to his permissions. To grant Jeff the access desired, I need to:
setfacl -m mask:rw- foo % getfacl foo # file: foo # owner: pbg # group: staff user::rw- user:jeff:rw- #effective:rw- group::r-- #effective:r-- mask:rw- other:r--
Now Jeff has read and write permissions to the file, while all others have only
read access. Of note is the slight change in behavior of the ls command.
Any file with specific ACL information is shown with a + at the end of the permission
field. Unfortunately, find doesn't seem to have an option to find all
files with ACL lists.
By now, your warning bells are probably going off. A hacker, having broken
into your system, could use the ACL facility to create back doors. These
back doors are very difficult to spot -- only inspection of ls output
will identify the target files.
Using the ACL facility on a directory adds some new twists. As well as setting
an ACL for the directory, you can set a default ACL for the directory. This default
ACL is used to set the ACL on every file created within the directory. The only
way I managed to get directory ACLs to work was using the -s option
with a very-long parameter string:
setfacl -s user::rwx,group::rw-,mask:r--,other:rw-,default:user::rw-,\ default:group::r-x,default:mask:rwx,default:other:r-x bar % ls -ld bar drwxr--rw-+ 2 pbg staff 512 Jul 22 14:11 bar % getfacl bar # file: bar # owner: pbg # group: staff user::rwx group::rw- #effective:r-- mask:r-- other:rw- default:user::rw- default:group::r-x default:mask:rwx default:other:r-x
Note:
I found that the FIRST time default ACLs are set, all of user, group, other and mask defaults must be set. This means that the first setfacl for a directory could be for instance:
$ setfacl -m d:u::rwx,d:o:---,d:g::---,d:m:rwx facltest/Once these four default ACLs have been set, subsequent "normal" calls to setfacl can be made, such as:$ setfacl -m default:user:myself:rwx facltest/
Now set a default ACL, and create a file in the directory:
setfacl -m default:user:jeff:rwx bar % getfacl bar # file: bar # owner: pbg # group: staff user::rwx group::rw- #effective:r-- mask:r-- other:rw- default:user::rw- default:user:jeff:rwx default:group::r-x default:mask:rwx default:other:r-x default:user::rw- default:user:jeff:rwx default:group::r-x default:mask:rwx default:other:r-x % touch bar/test % getfacl bar/test # file: bar/test # owner: pbg # group: staff user::rw- user:jeff:rwx #effective:r-- group::r-- #effective:r-- mask:r-- other:r--
There are several other aspects of ACLs, including deleting ACLs and using abbreviations and permission bit numbers (rather than symbols). This information is provided on the appropriate manual pages.
You can set default ACL entries on a directory that apply to files subsequently created within the directories. Files created in a directory that has default ACL entries will have the same ACL entries as the directory. When you set default ACL entries for specific users and groups on a directory for the first time, you must also set default ACL entries for the owner, owner's group, others, and the mask.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Dear Editor of Softpanorama,
I read your article on Linux ACLs:
http://www.softpanorama.org/Commercial_linuxes/linux_acl.shtml
In which the author wrote:
======
Of note is the slight change in behavior of the ls command. Any file with specific ACL information is shown with a + at the end of the permission field. Unfortunately, find doesn't seem to have an option to find all files with ACL lists.By now, your warning bells are probably going off. A hacker, having broken into your system, could use the ACL facility to create back doors. These back doors are very difficult to spot -- only inspection of ls output will identify the target files.
======This is not entirely accurate! I figured out a way to recursively list the absolute path of all files with an ACL. They mentioned the files will have a plus sign (+) at the end of the permissions field. By using a combination of find, ls, and egrep you can list these files:
find $PWD -exec ls -ld {} \; | egrep '^.{10}\+'
I ran this in a bash shell using CentOS 6.2 in VirtualBox.
|
|
|
InformIT
On an ext3 filesystem, read, write, and execute permissions can be set for the owner of the file, the group associated with the file, and for everyone else who has access to the filesystem. These files are visible with the ls -l command. Refer to Chapter 4, "Understanding Linux Concepts," for information on reading standard file permissions.
In most cases, these standard file permissions along with restricted access to mounting filesystems are all that an administrator needs to grant file privileges to users and to prevent unauthorized users from accessing important files. However, when these basic file permissions are not enough, access control lists, or ACLs, can be used on an ext3 filesystem.
ACLs expand the basic read, write, and execute permissions to more categories of users and groups. In addition to permissions for the owner and group for the file, ACLs allow for permissions to be set for any user, any user group, and the group of all users not in the group for the user. An effective rights mask, which is explained later, can also be set to restrict permissions.
To use ACLs on the filesystem, the acl package must be installed. If it is not already installed, install it via Red Hat Network as discussed in Chapter 3.
Enabling ACLsTo use ACLs, they must be enabled when an ext3 filesystem is mounted. This is most commonly enabled as an option in /etc/fstab. For example:
LABEL=/share /share ext3 acl 1 2If the filesystem can be unmounted and remounted while the system is still running, modify /etc/fstab for the filesystem, unmount it, and remount it so the changes to /etc/fstab take effect. Otherwise, the system must be rebooted to enable ACLs on the desired filesystems.
If you are mounting the filesystem via the mount command instead, use the -o acl option when mounting:
mount -t ext3 -o acl <device> <partition>Setting and Modifying ACLsThere are four categories of ACLs per file: for an individual user, for a user group, via the effective rights mask, and for users not in the user group associated with the file. To view the existing ACLs for a file, execute the following:
getfacl <file>If ACLs are enabled, the output should look similar to Listing 7.10.
Listing 7.10. Viewing ACLs# file: testfile # owner: tfox # group: tfox user::rwx group::r-x mask::rwx other::r-xTo set or modify existing ACLs, use the following syntax:
setfacl -m <rules> <file>Other useful options include --test to show the results of the command but not change the ACL and -R to apply the rules recursively.
Replace <file> with one or more space-separated file or directory names. Rules can be set for four different rule types. Replace <rules> with one or more of the following, and replace <perms> in these rules with one or more of r, w, and x (which stand for read, write, and execute):
- For an individual user:
u:<uid>:<perms>- For a specific user group:
g:<gid>:<perms>- For users not in the user group associated with the file:
o:<perms>- Via the effective rights mask:
m:<perms>The first three rule types (individual user, user group, or users not in the user group for the file) are pretty self-explanatory. They allow you to give read, write, or execute permissions to users in these three categories. A user or group ID may be used, or the actual username or group name.
CAUTION
If the actual username or group name is used to set an ACL, the UID or GID for it are still used to store the ACL. If the UID or GID for a user or group name changes, the ACLs are not changed to reflect the new UID or GID.
But, what is the effective rights mask? The effective rights mask restricts the ACL permission set allowed for users or groups other than the owner of the file. The standard file permissions are not affected by the mask, just the permissions granted by using ACLs. In other words, if the permission (read, write, or execute) is not in the effective rights mask, it appears in the ACLs retrieved with the getfacl command, but the permission is ignored. Listing 7.11 shows an example of this where the effective rights mask is set to read-only, meaning the read-write permissions for user brent and the group associated with the file are effectively read-only. Notice the comment to the right of the ACLs affected by the effective rights mask.
Listing 7.11. Effective Rights Mask# file: testfile # owner: tammy # group: tammy user::rw- user:brent:rw- #effective:r-- group::rw- #effective:r-- mask::r-- other::rw-The effective rights mask must be set after the ACL rule types. When an ACL for an individual user (other than the owner of the file) or a user group is added, the effective rights mask is automatically recalculated as the union of all the permissions for all users other than the owner and all groups including the group associated with the file. So, to make sure the effective rights mask is not modified after setting it, set it after all other ACL permissions.
If the ACL for one of these rule types already exists for the file or directory, the existing ACL for the rule type is replaced, not added to. For example, if user 605 already has read and execute permissions to the file, after the u:605:w rule is implemented, user 605 only has write permissions.
Setting Default ACLsTwo types of ACLs can be used: access ACLs, and default ACLs. So far, this chapter has only discussed access ACLs. Access ACLs are set for individual files and directories. Directories, and directories only, can also have default ACLs, which are optional. If a directory has a default ACL set for it, any file or directory created in the directory with default ACLs will inherit the default ACLs. If a file is created, the access ACLs are set to what the default ACLs are for the parent directory. If a directory is created, the access ACLs are set to what the default ACLs are for the parent directory and the default ACLs for the new directory are set to the same default ACLs as the parent directory.
To set the ACL as a default ACL, prepend d: to the rule such as d:g:500:rwx to set a default ACL of read, write, and execute for user group 500. If any default ACL exists for the directory, the default ACLs must include a user, group, and other ACL at a minimum as shown in Listing 7.12.
Listing 7.12. Default ACLs# file: testdir # owner: tfox # group: tfox user::rwx group::r-x mask::rwx other::r-x default:user::rwx default:group::r-x default:other::r--If a default ACL is set for an individual user other than the file owner or for a user group other than the group associated with the file, a default effective rights mask must also exist. If one is not implicitly set, it is automatically calculated as with access ACLs. The same rules apply for the default ACL effective rights mask: It is recalculated after an ACL for any user other than the owner is set or if an ACL for any group including the group associated with the file is set, meaning it should be set last to ensure it is not changed after being set.
Removing ACLsThe setfacl -x <rules> <file> command can be used to remove ACL permissions by ACL rule type. The <rules> for this command use the same syntax as the setfacl -m <rules> <file> command except that the <perms> field is omitted because all rules for the rule type are removed.
It is also possible to remove all ACLs for a file or directory with:
setfacl --remove-all <file>To remove all default ACLs for a directory:
setfacl --remove-default <dir>Preserving ACLsThe NFS and Samba file sharing clients in Red Hat Enterprise Linux recognize and use any ACLs associated with the files shared on the server. If your NFS or Samba clients are not running Red Hat Enterprise Linux, be sure to ask the operating system vendor about ACL support or test your client configuration for support.
The mv command to move files preserves the ACLs associated with the file. If it can't for some reason, a warning is displayed. However, the cp command to copy files does not preserve ACLs.
The tar and dump commands also do not preserve the ACLs associated with files or directories and should not be used to back up or archive files with ACLs. To back up or archive files while preserving ACLs use the star utility. For example, if you are moving a large number of files with ACLs, create an archive of all the files using star, copy the star archive file to the new system or directory, and unarchive the files. Be sure to use getfacl to verify that the ACLs are still associated with the files. The star RPM package must be installed to use the utility. Refer to Chapter 3 for details on package installation via Red Hat Network. The star command is similar to tar. Refer to its man page with the man star command for details.
|
|
|
freshmeatAbout: pyxattr is a Python extension module wrapper for libattr, which can be used to query, list, add, and remove extended attributes from files and directories.
Changes: A new set of functions with a different, namespace-aware API has been added. The license has been changed to LGPL 2.1.
|
|
|
Linux.comThe traditional file permission model, where read, write, and execute permissions are set on each file for the user, group, and others (UGO) has one drawback: It can't be used to define per-user or per-group permissions. For that, you need to employ access control lists (ACL). Eiciel is a graphical tool that integrates with the Nautilus file manager and allows for easy ACL management.
The UGO model lets you associate only one group with a file. If you try to define read permissions on a file for user Charlie and read and write permissions for user Alexia, and Charlie and Alexia belong to different groups, you'll see what I mean. With ACLs, you can specify elaborate permissions for multiple users and groups.Although Eiciel is a GNOME tool, you can run it on KDE as well if you have the necessary GNOME libraries installed. ACL supports is natively available in the 2.6 kernel, and ext2, ext3, XFS, JFS, and ReiserFS filesystems are ACL-capable.
You can install Eiciel from official software repositories of your distribution using apt-get or yum. Once installed, Eiciel is available as a standalone application or as a Nautilus extension, but you'll have to restart Nautilus before you can take advantage of the extension. After restarting Nautilus with the
killall nautiluscommand, to define ACL entries, right-click on a file and select Properties, then click the Access Control List tab.ACLs too rely on the traditional read, write, and execute permissions defined for each user and group. To define ACLs for users and groups, add them to the access control list by selecting them from the bottom half of the window and clicking Add. You can then define permissions for each of the users or groups you just added. The user and groups are listed under Entry with three check-boxes corresponding to read, write, and execute. You can thus define any concoction of permissions for the users and groups of your choice.
|
|
|
www.samag.com
Why use Access Control Lists (ACLs)? Aren't traditional Unix file permissions enough for any situation? Consider, for example, a semester-long software engineering course in which 30 students work in three-member teams on two projects. With traditional Unix permissions, each team/project combination would require a group, because all the team members must be able to collaborate, but teams must be isolated. Additionally, the professor needs access to project files for grading and for remote assistance. With this setup, the systems administrator would need to create 20 unique groups for each semester. If there were four such courses, there would be 80 groups; and if there were four projects, there would be 160 groups. With standard Unix permissions, the students cannot administer the groups themselves and the permissions are not flexible enough to allow the students to share their files with only members of their teams. This obviously becomes a management nightmare and a lot of work for the administrator.
Another example in which Unix permissions are inadequate is a mail server at a typical ISP. The ISP has a mail process that runs as user mail and file system quotas are enforced on both individuals (users) and organizations (groups). The mail process must be able to read and write the spool files, but not allow other users to read those same files (we assume no security flaws in the mail process). The admin is forced to make the mail spool files belong to the mail group while the files themselves are owned by the specific users. The admin can only (automatically) enforce quotas for users and not groups in this scenario, which is a potential loss of revenue for the ISP, who would prefer the more stringent of the group/user quotas to be enforced.
Linux supports POSIX ACLs in the stock 2.6 kernel. Linux implements ACLs based on two POSIX drafts -- 1003.1e and 1003.2c -- even though official sponsorship of those drafts was withdrawn in 1998. FreeBSD and Solaris also have almost identical ACL semantics.
|
|
|
OverviewThis document provides a solution to reduce the effectiveness of most buffer overrun exploits by preventing the effective user id of the compromised process from accessing a shell or other "popular" process from which to pursue his/her attack. This is an extremely simple technique utilizing POSIX ACL's (Access Control Lists) and does not introduce any additional load on a modern OS.
Credits
Concept: Kristofer Spinka ([email protected]) Proof of Concept: TBD
Concept
This works as is on Linux and Linux, however RedHat temporarily removed support for getxattr()/setxattr() which actually implements "setfacl -m"; I think they had a stability problem. It works as expected on Linux, but of course, it's Linux. If you encounter non-standard limitations on other platforms, please provide feedback.
- First make a dummy shell for testing and verification
vi shell.c: ----------- #include <unistd.h> int main(int argc, char *argv[]) { write(1, "shell started!\n", 15); return 1; } ----------- gcc -o shell shell.c- Create a "web server user" for testing. This is only temporary, we will remove it after testing.
become root groupadd -g 57470 facltest useradd -c "setfacl test account" -d /tmp/facltest -g facltest -s /bin/bash -m -u 57470 facltest passwd facltest (set a password for the account) drop root- Execute
setfacl -m u:facltest:--- shellThis will remove all permissions for user "nobody" from the file "shell".
- su - facltest attempt to execute "shell" created in step 1
- Cleanup test environment. userdel -r facltest groupdel facltest
- Apply facl's to all shells or other "popular" executables on your system for the account used to run network servies one by one, for example:
setfacl -m u:nobody:--- /bin/ash setfacl -m u:nobody:--- /bin/bash setfacl -m u:nobody:--- /bin/csh setfacl -m u:nobody:--- /bin/sh setfacl -m u:nobody:--- /usr/bin/es setfacl -m u:nobody:--- /usr/bin/ksh setfacl -m u:nobody:--- /bin/ksh setfacl -m u:nobody:--- /usr/bin/rc setfacl -m u:nobody:--- /usr/bin/tcsh setfacl -m u:nobody:--- /bin/tcsh setfacl -m u:nobody:--- /usr/bin/zsh setfacl -m u:nobody:--- /bin/sash setfacl -m u:nobody:--- /bin/zsh setfacl -m u:nobody:--- /usr/bin/esh setfacl -m u:nobody:--- /bin/dashYou should repeat this for *all* user accounts that run your network services, for example, the user account that httpd runs as, the user account named runs as, the user account sendmail runs as, etc.
ACL Interactions With Microsoft
Microsoft Windows has its own version of access control lists. When PC users Citrix MetaFrame users write files from Windows to the BCG storage server via samba, the Microsoft ACL associated with a file is translated to a Unix ACL. Sometimes this is done only by setting the standard Unix permissions.In other cases, the Linux ACL system described above is used. An ACL is usually set when a file's "Properties->Security" menu is modified. For example, if you grant another user access to a file through Windows, you'll find a '+' sign on the permissions when you list it from Linux. You can remove the ACL with
rmaclcommand described above, but then the user to whom you granted access from Windows will no longer be able to access the file.
Google matched content |
Linux Advanced System Administrator's Guide, Second Edition Understanding System Security
The classical user/group/everyone file permissions that the UNIX world has been used to the last 30 years, is pretty much an assumed. Nowadays, however, many UNIX implementations allow for granular file access control lists. Most UNIX administrator's still avoid them because they are not as apparent to them when doing a file listing.
I decided to be different. I wrote a tool to enhance the standard "ls" command into displaying file ACL's.
Under Linux, the ACL type can be one of the following:
user group mask otherFor directories only
default_user default_group default_mask default_otherA user or group can be specified to the user, group, default_user and default_group types. Linux ACL permissions are the normal UNIX permissions bits `rwx', where:
r - Grants read privileges. w - Grants write privileges. x - Grants execute privileges.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March, 12, 2019
