|
|
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 | |||||||
Softpanorama > Access Control in Operating Systems
|
|
NOTE: For a full version of Professor Bezroukov lecture to FDU students (Operating systems internals course) see Introduction to Unix ACLs
Files and directories in Unix have permission sets for the owner of the file, the group associated with the file, and all other users for the system. However, these permission sets have limitations. For example, different permissions cannot be configured for different users. Access Control Lists (ACLs, pronounced “ackkls”)) were implemented as an attempt to overlay per-user permissions framework on the classic Unix permission scheme. They act mainly at Unix groups level providing the ability for a file to be owned by several groups, instead of single group like is classic Unix permission scheme. They have higher priority then standard Unix permission and overwrite them in case of conflict.
|
|
Theoretically ACL provides better file security by enabling you to define file permissions on "per-user/per group" basis. Simplifying they can be viewed as several user-defined layers of classic Unix permission overlaid on each other. ACLs provide inheritance of attributes from directories to files via so called default permissions (which exists only for directories) and generalize umask concept by applying it to read and write operations, in addition to file creation like in classic Unix.
The biggest downside of ACLs is overcomplexity. Even such a simple and elegant scheme as classic Unix permissions is not that easy to understand fully and have several special cases which most sysadmin are not aware of. ACLs increase the level of complexity by an order of magnitude which put full understanding of this model beyond regular sysadmin intellectual capabilities. And it goes without saying that complex side effects of the scheme are much more dangerous, then in case of relatively transparent classic Unix permissions. Due to this ACLs has a huge potential to reduce the level of security instead of improving it, just due to limitations of humans intellectual capacities. Limitations which lead to errors inevitably introduced when dealing with this level of complexity.
Moreover, the lack of good integration ACLs and regular Unix permission and low level of visibility of ACLs in standard Unix commands such as ls make ACL perfect instrument for creating backdoors.
But at the same time it is unwise completely throw out those capabilities. So the key question is what subset of ACL provides maximum return on investment. My impression is that the ability to add groups is the capability for which game worth the candles. For example, for operator account can via ACLs allow access to selected files (and first of all to syslog files), without jeopardizing security, which happens when you grant such an access to world.
Another example is then you have two groups of people within which all need to have access a file (or a group of file), but all members of the group need read access and just two need write access (readers vs authors problem). With standard UNIX permissions, you cannot give write permission to only two members of a group. You can, however, set up an ACL for that file to grant only two people in the group write permissions on that file. In other word ACLs provide mean to give write access to file to selected members of the group, when granting such access to all members of the group is iether dangerous or unnecessary. This selective enabling of permissions if a very valuable feature which in impossible in Unix as group can't contain other groups as an explicit members and each file can have only one group assigned to it. See also ACL Permissions for Directories which expends this idea to a new level.
ACLs are also necessary if you export a Windows filesystem to Linux/Unix via NFS.
By default, if the file system being exported by an NFS server supports ACLs and the NFS client can
read ACLs, then ACLs are utilized by the client system. To disable ACLs on NFS share when mounting
it on a client, mount it with the noacl option with the command line.
Linux with Samba, the free and open-source Server Message Block/Common Internet File System (SMB/CIFS) became a popular type of file server those days. The reason is simple: Samba leverage Linux as a reliable, high-performance file server. Recent versions of Samba has a lot of advanced features, including support for Windows NT domains and Active Directory (AD). By joining AD, a Samba-based file server has all the benefits of a Windows-based file server, minus the licensing cost. The drawback is that many sysamins don’t configure a crucial element: ACL support. Windows uses ACLs as primary file access control mechanisms and Windows users usually are more proficient in ACLs then Linux users. They are listed in each file Properties section by selecting the Security tab. That means that you can use ACLs via Samba without knowing how to manage them directly on the Linux server
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Slashdot
ACLs *ARE NOT NECESSARY* (Score:5, Insightful)
by Captain_Carnage ([email protected]) on Sunday February 25, @06:30PM EST (#82)
(User #4901 Info)ACLs are a Bad Idea (tm) (Score:1)There are two basic access needs that people need to have to data: the ability to READ the data, and the ability to MODIFY the data. In ALL cases (at least, in all useful cases), these priviledges can be granted using standard Unix permissions.
Let's say you have a directory full of files, and you need some people to be able to write to these files (which implies they'll also need to be able to read the files, to verify their changes), and you have another group of people who needs to be able to read the files. Everyone else in the organization should have NO access. This is the most complicated case.
Can this be done with standard Unix permissons? At first glance, you might think that you can't, because the only permissions provided in Unix are User (owner), Group, and Other (world). You can't control the access for a second group, which is what you need, right?
However, the answer is YES! You can do this. Here's how:
Create one group each for the people who need to be able to read the files, and write the files. For simplicity of the example, let's call the groups "read" and "write" respectively.
Now, add every user who needs read access to those files to the "read" group, and add all users who need write access to BOTH groups.
Now, create a top level directory, like this (only ownerships, permissions, and the name are shown for brevity):
drwxr-x--- root read topdir
# mkdir topdir
# chgrp read topdir
# chmod 750 topdirBoth groups we created can cd into this directory (because we added the "write" group to the "read" group, remember?). Now, under that directory, create one or more directories where your data will be stored, like this:
drwxrwsr-x root write datadir
# cd topdir
# mkdir datadir
# chgrp write datadir
# chmod 2775 datadirThe '2' sets the SGID bit on the directory, which forces all files created in this directory to be created group-owned by the "write" group (it copies the group ownership of the directory to all new files in it). It will also make new files created in this directory group writable by default (again, copying the group permissions from the directory).
You might also want to prevent users from deleting files they don't own, by setting the sticky bit on the directory, which will make the '2' a '3' instead.
Now, users in the "write" group can create and write to files in this directory, and users in the "read" group will be able to read them, because they will be readable by other (world). However, everyone else will NOT be able to read them, because in order to do so, they would have needed to be in the "read" group in order to cd into topdir to get to datadir (which is why we also included the users in the "write" group in the "read" group)!
Thus, your problem is solved. Do this for every directory where the groups of people who need each type of access are different. This is BETTER than ACLs because
- a) it is either the same amount of administrative effort than managing ACL's on a per-directory basis (but you manage group membership instead), or LESS administrative effort than managing ACLs on a per-file basis; and
- b) it FORCES you to organize your data heirarchically by who has access to it.
Get over ACLs... they are a waste of time and programming effort.
You could argue that you might want some third group of people to have write access ONLY, but the practical value of this is very limited. If you feel that you need this you are probably being silly or WAY too paranoid, even for a system administrator. Limiting people from reading data that they can over-write is generally nonsensical.
I don't deny that there are certain very narrow applications for that sort of access limitation, but the likelihood that such an application would also present the need to have groups with each of those access requirements (read, read/write, and write-only) seems rather slim.
Note to slashdot maintainers: PLEASE make the damn text box for typing comments into bigger! The one currently provided on the web form makes typing long comments especially painful. And allowing the CODE HTML tag would be nice too.
by tbray on Sunday February 25, @10:35PM EST (#110)
(User #95102 Info)ACLs are too cumbersome to maintain (Score:1)IMHO the original Unix user-group-world read-write-execute is one of the great 80/20 points in computing history. The biggest downside of ACLs is their potential to reduce security due to inevitable human error introduced in dealing with the complexity.
Perhaps the canonical example is (old-fart alert) release X.0 (I forget X) of the late unlamented VAX/VMS, which ignored all the lessons of Linux except for (in early releases) the user-group-world model, except for they added an idiotic and useless "delete" access.
Anyhow, in X.0, VMS introduced ACLs; rather good and clean ones. Unfortunately, they screwed up the ACL on one of the core system name translation tables, and left it wide-open to subersion by anybody who wandered by and noticed.
I tend to think that this pattern is the rule rather than the exception... the cost of ACLs immensely exceeds the benefit, which isn't hard since it's often negative.
Cheers, Tim
by herbierobinson on Monday February 26, @03:07AM EST (#134)
(User #183222 Info) http://www.curbside-recording.com/hrmusic/index.htmlACLs (at least in the implementations I've seen) are too cumbersome because they are too hard to maintain. One ends up having to copy the same ACl onto hundreds of directories (which is not so bad). The bad part is when have to change it: You need a tree walk program to make the change to all 100 directories.
One possibility would be to have some named object in the file system which defines a set of access rights. That named object would be referenced from all the directories (and optionally files) it should control access to.
There are a number of articals in the latest JACM on security which are very relevant to this discussion, too. One of them discussed making access control be task based rather than object based. In other words, users get assigned to one or more tasks (aka groups) and each task defines the access to all ojects somehow (the somehow is the hard part...).
ACLs are really not enough. (Score:4, Insightful)
by Anonymous Coward on Sunday February 25, @03:28PM EST (#59)I've worked with ten or twelve operating systems at the system administration level, and I've done so in academic, corporate, medical, and military-industrial settings.
Most of the proprietary Unices (if you count different *nixen as separate OSes, double the OS count given above) have their own lame, incompatible implementations of ACLs. These are typically layered over the antique Unix rwxrwxrwx scheme.
"rwx" is insufficient. People often exhort others to "think unix" - and when you are talking about pipes & I/O redirection, or any of the other wonderful features of Unix, that's great. But if you "think unix" to the extent that you can't see how fundamentally LAME the unix access control mechanisms are, you are crippling yourself. To put it in perspective, consider the IBM MVS file protection system RACF - in RACF, you cannot grant a user write permission without also granting read permission. This is partially because of the underlying architecture of MVS, but that doesn't mean it's not lame and restrictive. However, most hardcore mainframers literally cannot conceive of a situation where they'd want write and not read.
Novell has the most advanced and useful system of file attributes I am aware of. For example, "create" and "write" are separate - this allows the creation of dead-drop boxes; folders where a user can create a file but cannot afterwards modify it. If you can't conceive a situation where you could put this to use, you are "thinking unix" to the point of wearing blinders. NOTE: the forgoing statement will cause this post to be labeled "flamebait" and modded into oblivion by self-righteous Berkleyites >:^} while simultaneously generating dozens of "oh yeah name one" followups.
There are many other aspects of the Novell system of file protection and user rights that are very advanced. Consult your local guru, but I'll mention "rename inhibit" as one useful ability. If Stef Murky, excuse me, Jeff Mirkey, ever gets his MANOS opsystem going under the GPL I personally will immediately convert to his Novell-clone filesystem. Even DEC VMS does not compare, and the VMS access control mechanisms beat Unix hands down.
I don't recommend Novell because it's not Open Source and because the complexity of X500 or NDS type "directory" systems adds instability and management overhead that is seldom warranted to achieve concrete goals. That being said, as the world becomes increasingly networked the previous statement becomes increasingly less accurate.
LDAP interfaces to SQL backends like MySQL and Postgres will eventually be the way to go (but not today, and ADS will never fit the problem space). The one warning I would sound is that when you keep file data and file attributes in separate places - as many systems do - you markedly decrease the robustness of your system. User data in the user directory, file attributes in the file header, is a better idea. Just like it's a better idea to put the comments in the source code than in a separate documentation file (don't get me started about that stupid practice).
Sorry my .02 pence is so lenghty. I could rant some more, but I think I got the major point across - ACLs on a "rwxrwxrwx" system is like streamlining a 1954 Volkswagen Beetle.
Re:ACLs *ARE NOT NECESSARY* (Score:3, Insightful)
by coyote-san on Sunday February 25, @07:52PM EST (#91)
(User #38515 Info)There are three small problems with this scheme.
First, you run into combinatorical explosion in the real world. Try running through your example in a small CS department with 5 professors, 50 students, and each student enrolled in three classes. Everyone has to work in teams, but the teams are different in each class. So each student needs to see his own files, and *some* of the files in 6-12 other user accounts (with team sizes from 3-5 people). He can't see all because that would be "cheating."
Now maintain that over 5 years, as students enroll, graduate, etc.
The second problem is that ACLs often support much more than simple read/write/execute. There's "modify" vs. "append." That is so important that ext2 supports "append-only" as one of the extended attributes. There's "change attributes (chattr)" as a separate permission than "write." Some ACL systems even control your ability to "stat" a file, to determine its ownership, size, time of access, etc. Some of this can be handled by your scheme, but it makes it much more complex.
The final problem is that ACLs are far more powerful than most implementations would suggest. Besides being able to grant - or revoke - access to individuals for read/write/execute/modify/append/delete/chattr/stat, I've seen ACL specs which allowed restriction based on time-of-day, day-of-week, and even access terminal (local vs. network).
You can use 'cron' to automatically change some bits, but it's hard to set it up so that, e.g., the faculty can play games any time, the staff can play them after hours, and the students can play them on weekends.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Re:ACLs *ARE NOT NECESSARY* (Score:1)
by Captain_Carnage ([email protected]) on Sunday February 25, @10:53PM EST (#111)
(User #4901 Info)In the real world, in most cases, going through the trouble I describe is not necessary. It is only necessary in a (usually) small number of cases where there are two distinct groups of people that require two different types of access.
In the University example that you describe, it is unlikely that all of these classes will have people working in teams for every assignment. In many such courses, the students' work is entirely individual.
In those cases where it is not, you simply need to create a Unix group for each team. All of the files for that team's project are kept in a central project-related directory. There is no reason whatsoever for any user not in that group to have access of any kind to the files of that group's project, so a more complicated scheme is not necessary.
Moreover, the classes offered from semester to semester don't tend to change much, so for the most part the groups will stay the same too, so you're not likely to need to spend a lot of time maintaining that, nor are you likely to run out of groups, even in a much larger CS department.
In the "real world", your first case just isn't really a problem. I learned how to use Unix permissions from the sysadmin of my college, whose CS department has over a thousand users, who successfully employed this tecnique for years.
The second case, modify vs. append: To me the latter is just a special case of the former. I personally see no reason why one should be treated differently from the other. If you have a compelling reason why someone should be allowed to append data to a file, but not modify the data that's already in the file, I'd certainly like to hear it.
Your permission to stat a file is controlled by whether or not you have read access to the directory the file is in. What legitimate reason can you suggest for preventing a user from seeing SOME files in a directory they legitimately have access to, but not others? What practical purpose does this serve?
Re:ACLs *ARE NOT NECESSARY* (Score:2)
by Baki ([email protected]) on Monday February 26, @08:31AM EST (#143)
(User #72515 Info)Real world problems that suffer from mentioned combinatorial explosion, are too complex: The business model in such cases should be simplified. The solution to complex access schemes is not to add a complex technical implementation, but to simplify the scheme.
The (many) times I've seen ACL's in action to implement overly complex access control schemes, it became chaos, and nobody knew anymore who was allowed to see what, and why the ACL's were the way they were. Maybe massive bureaucratic measurements could prevent chaos in such cases, but one had better rethink the way permissions are granted.
As for modify/append: There are a couple of very specific (system) tasks where append-only might be useful, especially for logfiles that intruders may not tamper with. But for general purpose use, I don't see the need. Append-only can just as well be implemented as a write-only directory (a la /tmp on Unix systems) where a user can "append" a record by creating a new file. Then cat them all in order of mtime, and you have about the same.
Time-dependant access etc is insane to administer, and again IMO the business model should rather be simplified.
Maybe ACL's are nice for control-freak type of system administrators that don't have much work to do, but for normal situations they're no good.
|
|
|
From: John Valdes Subject: Re: Linux ACLs Date: Tue, 26 Oct 2004 22:34:59 -0500 User-agent: Mutt/1.2.5i
On Tue, Oct 26, 2004 at 09:22:51PM +0200, [email protected] wrote: > > On 26 Oct, Philippe wrote: > > > >> Are you looking at the POSIX 1003.1e ACLs in the ext2/3 filesystem or SE > >> Linux stuff? > > > > I thought the Linux ACL followed the Posix recommendations. This was > > discussed a couple of weeks ago with Mark. I think Mark has considered > > looking the Linux ACL API seriously. > > I searched high and low for the POSIX API and it still does not make > sense to me. There is no real documentation and the little I have > found does not agree with what I find on my own systems, so I > don't know what to do yet.I've only taken a cursory look at Linux ACLs (and ACLs in general), so the following may not be totally correct.Solaris's & Linux's ACL implementations have similar command interfaces (eg, "getfacl" and "setfacl" commands w/ similar syntax & output), and for the most part follow the POSIX 1003.2c ACL recommendations, but the ACL APIs used are quite different.
- Linux's seems to be modeled after that last (and withdrawn) draft (17) of the POSIX 1003.1e recommendation.
- From what I've read, Solaris's API is based on an earlier and apparently much simpler API.
The primary repository of info on Linux's implementation of ACLs is <http://acl.bestbits.at/>. There are copies of all the relevant manpages there (commands, system calls, and library functions), plus a link to a paper presented at USENIX 2003 which talks about the state of POSIX ACLs on Linux (<http://www.suse.de/~agruen/acl/linux-acls/>) as of the time of writing.
There are also links to the POSIX draft documents, FWTW. The ACL patches and information presented on this site are what were implemented in the 2.6 linux kernel (and in SELinux), so regardless of what becomes of the POSIX ACL "standard", it seems that this will be/is the Linux ACL standard (at least for now; we are talking about Linux afterall ;) ).
Note that besides the 2.6 kernel, I believe RedHat >= 8.0 as well as newer versions of SuSE at a minimum included ACL support in their shipping 2.4.x kernels.
BTW, the FreeBSD ACL API appears to be similar to the Linux API, and I'm guessing that the Mac OS X API if/when that comes will follow the FreeBSD one, so it looks like there'll be no avoiding the more complicated API if one wants cross-platform ACL support in cfengine... ;)
John
|
|
|
Date: Tue, 24 Oct 2000 12:21:04 +0100 From: "Stephen C. Tweedie" <[email protected]> To: Andreas Gruenbacher <[email protected]> Subject: Re: [PROPOSAL] Extended attributes for Posix security extensions Hi, On Sun, Oct 22, 2000 at 04:23:53PM +0200, Andreas Gruenbacher wrote: > > This is a proposal to add extended attributes to the Linux kernel. > Extended attributes are name/value pairs associated with inodes.What timing --- we had a long discussion (actually, several!) about this very topic at the Miami storage workshop last week.
One of the main goals we had in getting people together to talk about extended attributes in general, and ACLs in particular, was to deal with the API issues cleanly. In particular, we really want the API to be at the same time:
- General enough to deal with all of the existing, mutually-incompatible semantics for ACLs and attributes; and
- Specific enough to define the requested semantics unambiguously for any one given implementation of the underlying attributes.
These points are really important. We have people wanting to add ACL support to ext2 in a manner which Samba can use --- can we do POSIX ACLs with NT SID identifiers rather than with unix user ids? If we mount an NTFS filesystem, it will have native ACLs on disk. How does the API specify that we want NT semantics, not POSIX semantics, for a given request?
There is also the naming issue. There are multiple independent namespaces. For extended attributes, there may be totally separate namespaces for user attributes and for system ones, or there may be a common namespace with per-attribute system status. Again, these different sets of semantics _already exist_ on filesystems which Linux can mount (eg. NTFS, JFS and XFS), so the API has to deal with them.
There is already a kernel API which has this flexibility: the BSD socket API handles these issues through the concepts of protocol families and address families. Those same two concepts are perfectly matched to the extended attributes problem.
The proposal defines two "families" of attribute entities: attribute families and name families.
An attribute family might be ATR_USER or ATR_SYSTEM to specify that we are dealing with arbitrary user or system named extended attributes, or ATR_POSIXACL to specify POSIX-semantics ACLs. Obviously, this can be extended to other ACL semantics without revving the API --- a new attribute family would be all that is needed.
The "name family" is the other part of the equation. Attributes in the ATR_USER or ATR_SYSTEM families might be named with counted strings, so they would have names in the ANAME_STRING name family. POSIX ACLs, however, have a different namespace: ANAME_UID or ANAME_GID. The API cleanly deals with the difference between user and group ACLs. It also makes it easy to add support later on for more complex operations: if we want to add NT SID support to ext2 ACLs so that Samba and local accesses get the same access control, we can pass ANAME_NTSID names to the ATR_POSIXACL attribute family without changing the API.
Obviously the combinations of name types supported for any given attribute family will depend on the underlying implementation, but that's the whole point --- the API is expressive enough to define unambiguously what the application is trying to do, so that if the underlying filesystem doesn't support (say) POSIX ACLs, we get an error back telling us so rather than attempting to do an incomplete map of the POSIX request onto whatever the underlying filesystem happens to support.
Before we look at the syscall API in detail, there's one other point to note. It is common to want to read or set one individual attribute in isolation (even if it is an atomic set-and-get which is being performed on that attribute). Sometimes, however, you want to access the entire set of related attributes as an ordered list. ACLs are the obvious case: if you have underlying semantics which allow you to mix both PASS and DENY ACLs on a file, then the order of the ACLs obviously matters.
In such cases, you may sometimes want just to query or set the ACL for a specific user, but often you will want to do something more complex such as change the order of ACLs on the list or replace the entire list as a single entity --- and you want to do so atomically. So, the simple "SET" and "GET" operations on named attributes (which correspond to writing and reading the ACLs for specific named users in the ATR_POSIXACL family) need to be augmented with SET variants which append or prepend to the ACL list, or which atomically replace the old ACL list in its entirety.
Our proposed kernel API looks something like this:
sys_setattr (char *filename, int attrib_family, int op, struct attrib *old_attribs, int *old_lenp, struct attrib *new_attribs, int new_len); sys_fsetattr(int fd, int attrib_family, int op, struct attrib *old_attribs, int *old_lenp, struct attrib *new_attribs, int new_len);where <op> can beATR_SET overwrite existing attribute ATR_GET read existing attribute ATR_GETALL read entire ordered attribute list (ignores new val) ATR_PREPEND add new attribute to start of ordered list ATR_APPEND add new attribute to end of ordered list ATR_REPLACE replace entire ordered attribute listand where <attribs> is a buffer of length <len> bytes of variable length struct attrib records:
struct attrib { int rec_len; /* Length of the whole record: should be padded to long alignment */ int name_family; /* Which namespace is the name in? */ int name_len; int val_len; char name[variable]; /* byte-aligned */ char val[variable]; /* byte-aligned */ };ATR_SET will overwrite an existing attribute, or if the attribute does not already exist, will append the new attribute (ie. it does not override existing ACL controls, in keeping with the Principle of Least Surprise). If multiple instances of the name already exist, then the first one is replaced and subsequent ones deleted. If supplied with an "old" buffer, all old attributes of that name will be returned.
For the PREPEND/APPEND/REPLACE operations, the entire old attribute set is returned.
For GET, the <new> specification is read and all attributes which match any items in <new> are returned, in the order in which they are specified in <new>. The actual value in <new> is ignored; only the name is used.
For GETALL, <new> is ignored entirely.
*old_lenp should contain the size of the old attributes buffer on entry. It will contain the number of valid bytes in the old buffer on exit. If the buffer is not sufficiently large to contain all of the attributes, E2BIG is returned.
This is just a first stab at documenting what feels like an appropriate API. It should be extensible enough for the future, but is pretty easy to code to already --- existing filesystems don't have to deal with any complexity they don't want to.
Additionally, the use of well-defined namespaces for attributes means that in the future we can implement things like common code for generic attribute caching, or process authentication groups for non-Unix-ID authentication tokens, without having to duplicate all of that work in each individual filesystem.
The extended attribute patch currently on the acl-devel group simply doesn't give us the ability to do extended attributes on any filesystem other than ext2, because it has such specific semantics. I'd rather avoid that, and I'd rather do so without adding a profusion of different ACL and attribute syscalls in the process.
Cheers, Stephen
|
|
|
Traditionally, systems that support the POSIX (Portable Operating System Interface) family of standards [11,2] share a simple yet powerful file system permission model: Every file system object is associated with three sets of permissions that define access for the owner, the owning group, and for others. Each set may contain Read (r), Write (w), and Execute (x) permissions. This scheme is implemented using only nine bits for each object. In addition to these nine bits, the Set User Id, Set Group Id, and Sticky bits are used for a number of special cases. Many introductory and advanced texts on the UNIX operating system describe this model [19].
Although the traditional model is extremely simple, it is sufficient for implementing the permission scenarios that usually occur on UNIX systems. System administrators have also found several workarounds for the model's limitations. Some of these workarounds require nonobvious group setups that may not reflect organizational structures. Only the root user can create groups or change group membership. Set-user-ID root utilities may allow ordinary users to perform some administrative tasks, but bugs in such utilities can easily lead to compromised systems. Some applications like FTP daemons implement their own extensions to the file system permission model [15]. The price of playing tricks with permissions is an increase in complexity of the system configuration. Understanding and maintaining the integrity of systems becomes more difficult.
Engineers have long recognized the deficiencies of the traditional permission model and have started to think about alternatives. This has eventually resulted in a number of Access Control List (ACL) implementations on UNIX, which are only compatible among each other to a limited degree.
This paper gives an overview of the most successful ACL scheme for UNIX-like systems that has resulted from the POSIX 1003.1e/1003.2c working group.
After briefly describing the concepts, some examples of how these are used are given for better understanding. Following that, the paper discusses Extended Attributes, the abstraction layer upon which ACLs are based on Linux. The rest of the paper deals with implementation, performance, interoperability, application support, and system maintenance aspects of ACLs.
The author was involved in the design and implementation of extended attributes and ACLs on Linux, which covered the user space tools and the kernel implementation for Ext2 and Ext3, Linux's most prominent file systems. Parts of the design of the system call interface are attributed to Silicon Graphics's Linux XFS project, particularly to Nathan Scott.
|
|
|
Q: Is there support for ACLs (Access Control Lists) in Linux?
A: Yes, there is - from multiple development projects, with divergent approaches, all aiming to allow the administrator some means of specifying what capabilities a process is to be allowed, and other fine-grained permissions (including Mandatory Access Control labels, Capabilities, and auditing information). At this time (May 2001), all require modifications (third-party, unofficial kernel patches) to the Linux kernel's filesystem and VFS code (umask and access-control modifications), which sometimes take a while to catch up with new kernel releases. The kernel maintainers have not endorsed any one approach. Thus, implementing any of these approaches remains an advanced topic using experimental code.
Further, there is not broad agreement on what filesystem it is best to use with ACLs. The obvious choices are ext2 + extended-attributes extensions, Steven Tweedie's ext3 (ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs/), the AFS implementations from IBM/Transarc (http://www.openafs.org/) or the Arla Project (http://www.stacken.kth.se/projekt/arla/), GFS (http://www.globalfilesystem.org/), SGI's XFS (http://linux-xfs.sgi.com/projects/xfs/), or ReiserFS (http://www.namesys.com/).
Adding further confusion is that the leading candidate for an ACL standard, IEEE Std 1003.1e, was withdrawn by the IEEE/PASC/SEC working group while it was still a draft, on Jan. 15, 1998, and thus was never formally included in POSIX (http://wt.xpilot.org/publications/posix.1e/). It nonetheless remains influential.
Generic "capabilities" support is included in 2.2 and greater kernels, including a control in /proc called the "capabilities bounding set". Many "capabilities" operations will also require libcap, a library for getting and setting POSIX 1003.1e-type capabilities, which you can find at ftp://ftp.de.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/ . See also the Linux Kernel Capabilities FAQ: ftp://ftp.de.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0.2.txt .
The VFS patches, filesystems extensions or other filesystem facilities to store ACLs, patches for fsck utilities (preventing them from "cleaning up" your extended attributes), patches for GNU fileutils, patches for the quota tools, and administrative tools must be provided by the various unofficial ACL-on-Linux projects, of which there are several.
In addition to applying any applicable patches to your kernel, you will have to enable three kernel-configuration options (all in the "filesystems" section): "Extended filesystem attributes" (CONFIG_FS_EXT_ATTR), "Access Control Lists" (CONFIG_FS_POSIX_ACL) and "Extended attributes for ext2" (CONFIG_EXT2_FS_EXT_ATTR). In order to be offered these configuration options, you must also select "Prompt for development and/or incomplete code/drivers" (CONFIG_EXPERIMENTAL) in the code-maturity level options, towards the beginning of kernel configuration.
The AFS distributed storage system, originally developed at CMU, generically has built-in support for ACLs. As such, it seems reasonable to suspect that IBM/Transarc's leading AFS implementation on Linux, due to have an open-source (GPLed) development fork on the near future, would include ACL support. We have been unable to confirm that from Transarc's documentation, thus far. This may change as Transarc completes its open-source rollout. (Unfortunately, Transarc's open-source fork will have a licence problem that will prevent it shipping with Linux-based systems: It will be issued under the IBM Public Licence, which, although open source, is not compatible with the GNU General Public Licence the Linux kernel is issued under.)
The pre-existing Linux AFS project, the GPL-licenced Arla Project, has reportedly been moving slowly. The quality of its ACL support is likewise unknown.
The existing documentation for AFS on Linux, unfortunately, makes no mention of ACLs or capabilities support: http://sarn.org/docs/linux-afs/faq.html http://web.urz.uni-heidelberg.de/Veranstaltungen/LUG/Vortraege/AFS/AFS-HOWTO.html
There have been two main attempts to implement POSIX ACLs on ext2 + extensions. One was the LiVE Project, at http://aerobee.informatik.uni-bremen.de/acl_eng.html . That effort appears to be now defunct.
The other, and probably your best bet for ACLs on Linux today, is Andreas Gruenbacher's Linux ACLs project, http://acl.bestbits.at/ . Gruenbacher has a well-developed ACL implementation with storage extensions for ext2, linking the extended attributes to inodes, and with ACLs among the data storable in those extended attributes. He expects that porting his subsystem to ext3 will be easy.
The Samba Project favours/encourages Gruenbacher's approach, and as of April 2001, Samba 2.2 will support his ACLs implmentation, if supported in the Linux kernel. (See: http://lists.samba.org/archive/samba-technical/2000-April/007619.html , http://us1.samba.org/samba/whatsnew/samba-2.2.0.html .)
The Linux Trustees Project (http://trustees.sourceforge.net/) is a non-POSIX, memory-based approach, loading all extended-attributes information from a database at startup.
RSBAC (http://www.rsbac.de/) is another Linux project to implement non-POSIX ACLs, along with a number of other security-architecture goals.
Linux-Privs (http://sourceforge.net/projects/linux-privs/) is a project to implement the entire POSIX draft on Linux, and has moved slowly but is cooperating with Gruenbacher, resulting in part in these patches/utilities for 2.2.x and 2.4.x kernels by Linux kernel programmer Andrew G. Morgan (with some code by Gruenbacher): ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/
The ReiserFS and GFS maintainers are aware of the desirability of adding extended-attribute support to their filesystems, but have not yet done so. Hans Reiser is believed to favour a system implementing Macintosh-style resource streams/forks of artbitrary length to store the extended information, rather than extended-attribute storage within the filesystem structure.
Andreas Dilger has spoken of the Intermezzo distributed file system project (http://www.inter-mezzo.org/) in the near future implementing extended attributes similar to Gruenbacher's, making future ACL support on that filesystem (which is still in early beta) likely.
The XFS filesystem maintainers have built in full support for POSIX ACLs.
The LIDS Project (http://www.lids.org/) implements some "capabilities" ideas, but not ACLs.
Last, Pavel Machek maintains an "ELF capabilities" kernel patch and matching utilities, which allow the admin to strip specified capabilities from binary executables at execution time. It does not provide other ACL-type capabilities. The information on what capabilities to drop for a given binary upon execution is stored inside the ELF header, in a manner compatible with ordinary Linux operation. The advantage to this approach is that it does not require extended-attributes support in the underlying filesystem. Full details are at http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html
|
|
|
Access Control Lists (ACLs) solve these problems. They allow more flexibility than the standard Unix user/group/other set of permissions. ACLs have been available in commercial UNIXes such as IRIX and Solaris (and in Windows NT) for years. Now, thanks to the TrustedBSD project's work, ACLs are available in FreeBSD 5.0-RELEASE and beyond. Much of the information below applies, at least in part, to ACL implementations on other platforms; however, you will want to look at specific documentation to avoid being tripped up by differences in syntax. There shouldn't be many, as FreeBSD attempts to conform to the latest
POSIX.1edraft.
|
|
|
Under the classic MULTICS system, which was also used by the PRIMOS operating system, each file has an ACL, with access such as the following:
- Read
- Write
- Traverse -- for directories
- Execute -- for data
- EditACL
The read and write rights should be obvious.
The traverse right is used in the context of hierarchical directory structures. A user who has no right to read or write a directory can mention that directory in the path name of a file as long as the user has traverse rights to that directory -- the user is just passing through, but may not open the directory to list its contents.
The right to edit an access control list illustrates one approach to allowing the contents of the access control matrix to be modified. In a sense, all users with the right to edit the access control list of an object can be thought of as co-owners of the object. If one user (the legitimate owner of an object) grants the right to edit that object's ACL to another user, it is like granting the other user a power of attourny over the object.
Example: the UNIX file system
Under UNIX, each file has an ACL, but the ACL is strictly limited in structure. Each UNIX ACL has 3 fixed entries:
- An entry for the owner of the file
- An entry for others in the same group as the the owner
- An entry for the general public
The rights associated with each entry are:
- Read
- Write
- Execute/Traverse
The MULTICS project originated as a joint project between MIT, GE and Bell Labs in the mid 1960's. In the late 1960's, Bell pulled out of the MULTICS project, largely because the technical staff of the computing group had concluded that MULTICS was getting too complicated. UNIX was born from this frustration, and the name UNIX is a pun on MULTICS -- suggesting a scaled down system designed to meet a scaled down set of goals.
The simple to implement ACL scheme of UNIX is an example of this. Unlike the MULTICS ACL, it is not general, but it meets the needs of most users of small computer systems. As a result, every UNIX ACL fits exactly in 9 bits of the I-node of the file it describes!
MULTICS was intended to meet the needs of a general information utility, and as such, it had to deal with the problems of large numbers of users, including users from competing organizations. The generality of the MULTICS access control list is well justified by this environment, and the success of PRIMOS in meeting the needs of compaines like Compuserve or The Source (modern examples of computer utilities) amply illustrates the appropriateness of the MULTICS design.
When UNIX systems are extended beyond single departments, the short ACL of UNIX becomes a problem.
Distributed versions of UNIX such as the Appolo Domain operating system have been forced to add general ACL's back onto the UNIX file model in order to meet the demands of the large user base that such a system can serve.
|
|
|
It was argued by some that the ugo access control method did not permit sufficiently fine-grained control for the advanced UNIX administrator. This led to the development and implementation of the POSIX (portable operating system interoperability standards) Access Control List (ACL) capabilities. Unfortunately, there is no universally recognized standard for UNIX ACLs; the one implemented by Samba is Draft standard 1003.1e revision 17. It specifies an application programming interface (API). The various differing ways vendors have implemented the POSIX ACL standards means that Samba must maintain its own interface layer that maps POSIX ACL system calls to the correct one for the host UNIX operating system. The pressure for Samba to support Windows ACLs has put pressure on the standardization of ACLs.
POSIX ACLs provide a meta-file extension of the UNIX ugo permissions. While designed to be simple in concept and in use, ACLs can quickly lead to great complications. ACLs can be set on files and on directories. The only modes of access each Access Control Entry (ACE) in an ACL supports are: read, write and execute (rwx).
Like ugo permissions, a reset value "-" for an access mode means deny, and a set value means permit. ACLs add the capabilities of setting inheritance and mask controls on files and directories. Masks override group permissions.
There are two -- and only two -- conditions that would warrant the creation of a POSIX ACL on a file or a directory:
- To provide an access exception for a user who is not a member of the primary group, or to provide and access exception for a group other than the owner-group.
- To specifically exclude particular users who are a member of the owner-group from accessing the file or directory.
One of the big challenges in the use of POSIX ACLs is backup and recovery of a backup. The UNIX tools cpio and tar do not permit POSIX ACLs to be backed up. The pax, star and dump tools do permit this, but few UNIX administrators are aware of these tools. Some UNIX systems with ACL support do not have the tools, or administrators do not use them.
This means that UNIX POSIX ACLs can easily get lost in the event of a major system failure that necessitates recovery from a backup medium. The potential for loss of essential file system meta-data must be considered a liability of use.
A POSIX file ACL can be obtained by executing:
getfacl a_fileIt has the following structure:# file: testfile <- the file name # owner: jeremy <-- the file owner # group: users <-- the POSIX group owner user::rwx <-- perms for the file owner (user) user:tpot:r-x <-- perms for the additional user tpot group::r-- <-- perms for the file group owner (group) group:engrs:r-- <-- perms for the additonal group engineers mask:rwx <-- the mask that is ANDed with groups other::--- <-- perms applied to everyone else (other)A directory ACL is obtained the same way and has the following structure:
# file: testdir <-- the directory name # owner: jeremy <-- the directory owner # group: jeremy <-- the POSIX group owner user::rwx <-- directory perms for owner (user) group::rwx <-- directory perms for owning group (group) mask::rwx <-- the mask that is ANDed with group perms other:r-x <-- perms applied to everyone else (other) default:user::rwx <-- inherited owner perms default:user:tpot:rwx <-- inherited extra perms for user tpot default:group::r-x <-- inherited group perms default:mask:rwx <-- inherited default mask default:other:--- <-- inherited permissions for everyone (other)Conditions That Impact Availability of ACLs in Samba/UNIX
Those who subscribe to the Samba mailing list will occasionally witness the consternation of administrators who are unable to create ACLs on the Samba host server from within the Windows Explorer. In all cases to date the problem has been a simple oveersight, either through lack of knowledge or through a simple little bit of information that was lost or forgotten during installation.
There are five parameters that must be met for Windows ACLs to function with Samba servers:
- kernel support
- file system support
- support libraries installed
- file system mounted with ACL support
- Samba compiled and linked with ACL support
(a) Kernel ACL Support
Kernel support for POSIX ACLs is native to most relatively current generation UNIX systems. This is not the case for many Linux systems. The Linux-2.4.x series kernel does not have native ACLs support and requires the addition of the BestBits ACLs patch before this functionality can be obtained. Linux-2.6.x kernels do have native ACLs support, but it must be selected and built into the currently generated kernel for this to function. The Linux-2.6.x kernel configuration file entries to enable ACLs are as follows:
CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_JFS_POSIX_ACL=y CONFIG_FS_POSIX_ACL=y CONFIG_XFS_POSIX_ACL=y CONFIG_NFS_ACL=y CONFIG_NFSD_ACL=y CONFIG_NFS_ACL_SUPPORT=yThese settings were obtained from the /usr/src/linux/.config file, and they highlight the filesystem types for which ACLs can be either enabled or disabled.
(b) File System Type Must Have ACL Support
The Linux file systems ext2fs, ext3fs, reiserfs, jfs, xfs, and nfs can all be ACL enabled. Such enablement is determined as shown above by having this support in the Linux kernel. UNIX system users should verify that support for ACLs is available in the file system type that is being used.
(c) ACL Support Library Availability and Samba ACLs Enablement
Linux systems require the installation of particular libraries. For example the linux-2.6.x kernel requires, for ACLs support, the availability of the
libacl.soandlibattr.solibraries. The RPM packages that provide these libraries are respectively called:libacl-2.2.25andlibattr-2.4.16. When Samba is compiled on a Linux system the respective development libraries must also be installed prior to compilation. Support for ACLs in the Samba executables can be validated by executing:merlin: # > smbd -b | grep ACL HAVE_SYS_ACL_H HAVE_POSIX_ACLS(d) File Systems Mounted with ACLs Support
UNIX/Linux systems that are ACL enabled may have file systems that have been mounted without ACL support. The best way to verify that mounted file systems have ACL support enabled can be done by executing:
merlin: # > mount /dev/mapper/system-ROOT on / type reiserfs (rw,acl,user_xattr) /dev/hda1 on /boot type reiserfs (rw,acl,user_xattr) /dev/sda5 on /data type reiserfs (rw,acl,user_xattr) /dev/mapper/system-VAR on /var type reiserfs (rw,acl,user_xattr) /dev/hdb1 on /data2 type reiserfs (rw,acl,user_xattr) frodo:/home on /home type nfs (rw,soft,rsize=8192,wsize=8192,posix,acl,addr=192.168.1.1) frodo:/home2 on /home2 type nfs (rw,soft,rsize=8192,wsize=8192,posix,acl,addr=192.168.1.1) nfsd on /proc/fs/nfsd type nfsd (rw)The above response from the mount query confirms that ACLs are supported on all mounted file systems, including NFS mounts.
When all the above conditions have been validated a simple test for ACL support can be conducted by executing the following:
merlin: # > touch testfile merlin: # > setfacl -m user:bin:rwx testfile merlin: # > getfacl testfile# file: testfile # owner: root # group: root user::rwx user:bin:rwx <==== This ACE proves that ACLs are supported group::rwx mask::rwx other::r--All things being equal, so to speak, ACLs support should now be possible through Samba. The next consideration in the use of Windows NT/200X ACLs by Windows workstation client users requires an understanding of how they are mapped to POSIX ACLs.
|
|
|
|
|
|
One of the features of Solaris 2.5 (the new OS that was recently installed on CNS Unix computers) is file ACLs (Access Control Lists). These allow you to have much finer control over access to your files and directories.
In the past, you could give read, write and execute access only to yourself (user), your group (group) and everyone else in the world (other). Now, besides those, you can give access to any individual users that you choose.
Let's say you have a group of people, yourself (sheridan), ivanova and kosh, working on a class project and a file named star_fury you all need to access.
Use the setfacl command (set file acl) to set ACLs for that file:
setfacl -s u::rwx,g::---,o::---,m:rwx,u:ivanova:rwx,u:kosh:rwx star_fury
The first user, group and other (where those names are followed by double colons) refer to the standard Unix file permissions. Mask works like the standard Unix umask. The rest of the command adds access for your group.
You can use the keywords user, group, other and mask or the first letter of those words and permissions can be specified in symbolic (rwx) or octal (7=rwx, 6=rw-, etc.) mode, so the following are all equivalent:
setfacl -s u::rwx,g::rw-,o::r-- star_fury setfacl -s u::7,g::6,o::4 star_fury setfacl -s user::rwx,group::rw-,other::r-- star_fury setfacl -s user::7,group::6,other::4 star_furyTo see which ACLs are set, use the getfacl (get file acl) command:
getfacl star_fury
# file: star_fury # owner: sheridan # group: other user::rwx user:ivanova:rwx #effective:rwx user:kosh:rwx #effective:rwx group::--- #effective:--- mask:rwx other:---You can also set default ACLs for directories, which will allow ACLs to be automatically set for any files that are created in those directories. To do this, make the directory:
mkdir bab5
and then set the ACL for the standard Unix groups (user, group, other) and mask and then the defaults for those same groups (using the keyword default or d):
setfacl -s u::7,g::6,m:4,o::6,d:u::7,d:g::5,d:m:7,d:o::5 bab5
Then you can set the defaults for your group (be sure to use the -m option to modify the defaults since the -s option deletes any existing ACLs before it sets a new ACL!):
setfacl -m d:u:ivanova:rwx,d:u:kosh:rwx bab5
and then to see what you've done:
getfacl bab5
# file: bab5 # owner:sheridan # group: 1012 user::rwx group::rw- #effective:r-- mask:r-- other::rw- default:user::rwx default:user:ivanova:rwx default:user:kosh:rwx default:group::r-x default:mask:rwx default:other::r-xand any files created in the bab5 directory will have read write and access permissions for yourself, ivanova and kosh.
For more information, see man setfacl, man getfacl or look at an online description in Sun World Online at
http://www.sun.com:80/sunworldonline/swol-08-1996/swol-08-security.html
Google matched content |
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: August 13, 2019
