Slashdot Mirror
Access Control Lists In Linux Filesystems?
oracleofbargth asks: "Is there any project for implementing ACLs in the various filesystems supported under linux (ext2, ext3, etc...) that has the potential to become an official part of the kernel, rather than just a patch to it? The Linux ACL Project looks good, but is ext2 specific. Trustees also looks promising, but a system implemented in the filesystem itself would be preferable. RSBAC also has ACL capabilities, but on the whole goes a bit overboard in terms of what I'm looking for. Ideally, I need something that will work with ext3 so that the ACL information will be journaled."
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.
.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.
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
--Charlie
And it's journalling and quick. The only problem is that they're running on a fork of the kernel, so you have to either pray that large patches will take properly, or keep CVS'ing it.
http://linux-xfs.sgi.com/projects/xfs/
Ooh, and pre-release 0.9 is out. So, get it, or something.
-Yarn - Rio Karma: Excellent
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 topdir
Both 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 datadir
The '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.
This is a networked file system, but OpenAFS has excellent support for ACLs. I am personally using it at Carnegie Mellon and its used at a host of other places like MIT. And its not a patch but simply a module you compile for the kernel. I got it running on my linux system in 15 minutes. Also has excellent support for security (see Kerberos).
http://www.lwn.net/2001/0222/kernel.php3
ReiserFS and NFS. The various problems that have bit (a small number of) ReiserFS users in 2.4 are being cleared up. But one larger problem remains: ReiserFS, as shipped in 2.4, does not support NFS. That limitation gets in the way of quite a few people who would like to use ReiserFS, but who also need to be able to export their filesystems.
For the short term, those who are not afraid of kernel patches can have a look at this message from Neil Brown describing where to get the patches he has made available. They are still under development, but they provide "reasonable NFS service" in their current state.
The picture for the longer term is a bit less clear. Neil has a plan for proper support of NFS with ReiserFS, and for improving NFS service in general. It is, however, a large change, requiring tweaks to every filesystem which needs to support NFS. Filesystem changes tend to make kernel hackers nervous, especially in the middle of a stable kernel series. And, in fact, Alan Cox responded that he was not interested in such an extensive patch.
Those who are curious about the troubles with NFS should look at Neil's justification for the changes. It is a lengthy, detailed, and well-argued discussion of how the current NFS implementation fails to mesh well with the various Linux filesystems, and exactly what needs to be fixed to make things work better. It was persuasive enough that Alan agreed that the approach made sense - for the 2.5 kernel series.
Thus, the 2.4 kernel may never support exporting of ReiserFS filesystems over NFS. Those who need this capability will have to apply the patch themselves. That is, if the distributors do not apply the patch themselves before shipping the 2.4 kernel. SuSE, at least, applied such a patch when it shipped ReiserFS with 2.2, so it would not be surprising to see that happen again.
cpeterso
The application (which includes the tools for manipulating ACLs) have to know what semantics are supported.
If there's a single VACL layer, any application that supports one underlying FS will support all.
If there's multiple ACL layers, then you'll need separate tools for each type of filesystem. This means you have to know what FS you're residing on. This is a Bad Thing (TM).
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
All existing applications will use the standard calls and either suceed or fail.
I think you're too quick to dismiss the idea of unified ACL tools, though. Could you imagine the chaos if the VFS didn't exist and you had to use "ls" on ext2, "dir" on dos/vfat/iso, "nls" on nfs, etc.? Can you imagine the pain of keeping track of which application works on each directory? Many people would prefer to see a minimal set of ACL semantics that work everywhere (if supported at all) than a more robust set that only works part of the time.
But the key point which I think you're missing is that you're thinking of ACLs as what lives on a Unix disk locally mounted. If you've mounted a NTFS partition, there is no "user/group" in the ACL, there's only a list of UUIDs. If you've mounted an AFS image, there's globally unique user-ids which may not correspond cleanly to your local users. (One thing everyone agrees on is that networked ACLs should not be vulnerable to the same trivial spoofing as NFS ownerships!)
Conceptually, all ACLs are doing the same thing so it should be possible to identify an abstraction. In practice, this hadn't been done at the time I last investigated the issue.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
The problem is that Unix filesystems only provide course control. ACLs provide much finer control.
An example of where ACLs would be required would be a well-run law or medical office. Each person would have their own user id, and would be in a couple groups. (Doctors, lawyers, secretaries, nurses, paralegals, etc., plus departmental groups.)
But confidentially still means that many files should be accessible only to a few people, e.g., one lawyer, one paralegal and one legal secretary. If someone goes on vacation, their replacement needs to have access during the period they're covering the regular person, but no longer. If someone else needs to be brought in for consultation, they might need read-only access for a while.
Try doing that with Unix permissions. It's possible, but it is *extremely* difficult and runs into combinatorical explosion with more than a handful of people. (Basically you need to create a "group" with every possible subset of users. You then change the group permissions to implement these semantics.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
I haven't been following the kernel discussion for some time, but I recall that there was some concern over how to handle ACLs.
The problem is that Linux supports a *lot* of different filesystems, and they often have different ACL semantics. (Think standard Unix ACLs, NT ACLs keyed by UUIDs, and network FS ACLs.) The way to implement any single set of semantics is obvious, but the way to implement a virtual ACL level so you can hide the details from applications is not.
Until this has been figured out -- or the cost of maintaining multiple ACL semantics outweighs the cost of not having ACL support -- all of the ACL patches will remain outside of the main kernel tree.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
A few co-workers and myself are writing a new filesystem that includes ACL support. It's also journaled, 64-bit, supports named streams, and has indexed directories.
It emulates unix-type bitmask permissions with ACLs, and optimizes for the common cases. This means that chown, chmod, chgrp, etc. will all work unmodified.
We should be ready to do an initial beta release in one to two months for Linux 2.2.18. After that, we'll have ports for Windows 2000, FreeBSD and maybe Linux 2.4 -- depending on how stable its VFS, VM, etc. interfaces look at the time. We also plan SOlaris and HPUX ports.
An additional feature is that file system metadata is endianness-independant, so you can use the same filesystem with big or little-endian hardware. And it will be possible to pull a drive out of a Linux machine running this FS, mount it under Windows 2000, copy data back and forth, set ACLs, etc, then put it back in the Linux machine and keep on using it. Which will be sweet. Of course, it'll also mean that people who dual-boot with Linux and Win2k can have a common filesystem.
We've tentatively named the filesystem "CXFS" -- but we realize that SGI also has a "CXFS." What do you think would be a good (short, meaningful, catchy) name for an efficient cross-platform journaled filesystem?
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
I've been playing around with XFS for a few weeks, and I must say it kicks total ass. It's a good bit faster than ReiserFS and seems to have fewer problems with latencies. On the Bonnie benchmark (which are apparently biased according to some kernel developers) XFS get 3x the I/Os per second, and in real world cp and tar testing, it is noticably faster. That said, it seems to also have ACL support.
A deep unwavering belief is a sure sign you're missing something...
Does anyone know what is keeping ACLs out of the kernel? Has Linus ever said where he stands on a standard ACL implementation for Linux?
/dev? Why can't I delegate the task of adding and deleting users to a minion without worrying they will corrupt the filesystem.
I asked Alan Cox about this and he said thatcapabilities were pretty much unrecognized by the wider comunity. But IMHO, cpaabilties aren't nearly as clean as ACLs.
There's a large portion of (well, dickheads, really) who think any idea implemented in NT doesn't belong in Linux. This ignored the fac that the Trusted flavos of varios closed source Unixes and VMS have had the same system for years. And that Microsoft, while not having the worlds best business practices, can occassionally make goodOS deesign decisions, and even sometimes be the best tool for the job.
I'm not sure what Linux would say, but I'd like to echo those sentiments exactly. There's no reason I, not and service, ever neeed to run as root. Why does my mail server need a small program with permissions to install a rootkit in
Sudo is a hack.
I think that's a little unfair. The comparison was between Tux2 and ext3, and if one is vapor then both are. They're at similar stages in development and their authors present similar pictures of their progress.
Except that you can download working ext3 code, and have been able to for more than a year. As of yet Tux2 is still design plans, without any public working implementation.
Tux2 has a much more interesting technology
Tux2 is still vaporware. I agree, it will be great when it comes out. However, it is currently vaporware.
ReiserFS and XFS are also really great,
So these have log structure (or btree) and journalling. However, ReiserFS is broken with NFS currently, and that is a BIG problem. XFS is still beta and not merged with the main kernel tree, which is also a BIG problem. Ever see the fallout when Alexander Viro (kernel VFS hacker) takes a newly merged filesystem to task ?? It is not pretty.
Ext3 has some advantages. It has been running stably for a long time now under development. It is journaled, and has a small code base. It also only exists for the 2.2 kernel series.
Phillips is also making a judgment call. He wants to build on ext2 with tux2. Ext2 is not log structured, which is why ReiserFS can beat it in well-structure benchmark tests run by Hans.
The future, IMHO, is a log structured file system with NO journaling and atomic updates. This creature already exists, and it is called FFS with Soft Updates, from the FreeBSD developers. Here is the breakdown.
Journalling is tricky, as it requires lots of intervention at other places in the kernel. You need to keep something synchronous - journalling just makes that something very small. Atomic updates avoid synchronous issues altogether. Instead, they structure the file system in groups of data and metadata. In each group, there is an atomic bit. When set, it means the group is intact. So, upon looking through the groups, you can immediately determine which ones are intact and which are incomplete. Recovery is REALLY fast after a power outage, in theory even faster than a journal recovery.
WRT log structuring and btrees, these allow small and large files to live together easily, and allow rapid searches in large directories. Both of these have substantial advantages.
And the future for linux file systems ?? I don't know, it is always interesting to see where things will head. The world is clamoring for easy crash recovery, and ext2's days are numbered. I think most people would be quite happy to simply add journaling to ext2. Or atomic updates. So I predict, after consulting the crystal ball, that tux2 develops a large following after release, and that Phillips then adds btree searches and log structuring, making it the first linux file system with all that.
That would then bring the state of the art file systems for linux up to par with those of FreeBSD. Of course, in linux at that time you can also use JFS, XFS, ReiserFS, or ext3 journaled file systems.
But journaling is worse than atomic updates, both for complexity and speed.
Okay, I know it's a bit off the topic of Linux and all, but isn't TrustedBSD working in ACL's into FreeBSD 5.0? I need to go back and read that interview again.
For myself, I know that ACL's are the #1 reason why my primary file server at work is still an NT. Maybe I just don't fully grasp all the ways you can tweak *nix file permissions. I just don't see how you can assign one group ownership rights, one group read/write, and yet another group read only while not allowing "everyone" any kind of access. How about allowing a group of folks the right to write to a file, but not delete it?
I do prefer FreeBSD for specific server tasks. Web serving is certainly the top of that list. Thing is, without the granularity of ACL's I can't leave NTFS behind when it comes to the more complex task of file sharing to a bunch of users on a LAN.
Additionally, I've gotten quite used to the notion of leaving the OS permissions to Everyone on my files on the server, then restrict access via the share permissions. The server itself is physically locked in a room so I'm not normally concerned with local security. As cool as Samba is, it makes no provisions for implementing permissions of any sort. Heck, for 95% of my ACL needs, they could be implemented in Samba and never touch the FS.
The line must be drawn here. This far. No further.
ACLs allow users to come up with quick workarounds to access control problems. It's easy for the administrator in the short run because people won't bother you about this or that. But you end up with an incomprehensible mess of access rights, and you end up with lots of questions of why something does or does not work.
The traditional UNIX system, instead, forces people to think ahead and define clearly what they are trying to accomplish. Then they define a group for that purpose. The end result is easier to understand and easier to analyze.
On balance, I'd rather not have ACLs. There is value in keeping things simple.
There are *such* better projects than ext3 that are so much further along its rediculous to think that ext3 has any chance of becomming the next standard filesystem. Tux2 has a much more interesting technology that could allow really great stuff, such as journaling of meta and file data. It'll even be possible to use its phase tree algorithm to allow online fscks (useful to check for decaying filesystems). ReiserFS and XFS are also really great, but Tux2 and ext3 are the only ones that can convert ext2 automatically. Daniel Phillips who's working on Tux2 is also pumping all sorts of other nifty features into the patch, such as tail merging and a system that puts btree efficiency into the FS without the complexity of btrees. Its way beyond the competition. Further, it should be ready for the 2.5 tree, while ext3 has been in development for 2 years...