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."
Oh, yeah? NAME ONE such situation!
--moribund meisterberger
I think that there needs to be some examination of what access control strategy gets implemented. The /etc/passwd, /etc/group and ACL thing is functional and simple, but it's too cumbersome and antiquated to run an enterprise network on.
This is from someone who has managed some very large NetWare, NT, and Unix networks and knows. NT is a little better than Unix is for administering rights, but NetWare stomps them both.
There are good and bad things about Novell's management architecture, but they have done an excelent job by objectifying everything and then specifying properties to those objects. The rights also are inherited so that you don't have to implicitly set rights on every directory or object. You can specify rights per object or per container. making it easy to clasify users. You can grant rights to just a certain user or group of users for a certain property of objects... for example, you can have a help desk container whose occupants have rights to reset the password atributes on users and manage the print queues, but the people in the help desk can't delete or add a user or give them any aditional rights.... cool eh?
Say you have one Help Desk person that you trust to do some file management, so you implicitly give him rights to the objects for the filesystems that he can manage.
ACLs are too limiting, we need to be looking at some objectified, hierarchical, rights system with granular rights to properties and global inheritance.
Once you use NetWare, groups and ACLs are bunk. We need something that cool.
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
Regarding the access vs. content stuff: What about having multiple versions of the same document? E.g. a complete one for the developers, and an executive overview for the users, and an executive executive overview with possibly some extra confidential long term strategic annotations for the PHBs? Those belong together (hell, they might even be derived from the same LaTeX source), yet security is very different. And next thing you know is that security requirements change (I've had this happen several times: stuff that starts out as "developers only" gradually gets propagated upwards and outwards.)
--
Linux user since early January 1992.
--
Linux user since early January 1992.
http://www.nsa.gov/selinux/
(Note to the conspiracy theorists: it's covered under the GPL, and source is available.)
Watch out for Samba 2.2 which should support NTFS ACLs on Linux (with bestbits patch), Solaris, HPUX and maybe a few others.
The neat thing is that this should drive the bestbits patch to be accepted into 2.4.
Hang on. Even though Linux supports lots of file systems, very few of them are "native". The native Linux file systems include ext2, ReiserFS, and the original ext (is it still around?). (Yes, I'm aware of XFS, JFS and ext3 but they are not ready yet). Files on these file systems have all the proper attributes (UID, GID and permissions). However, files on foreign file systems do not. For example, all files on fat16/fat32/ntfs/ have exact same UID, GID, and permissions. You can configure which UID, GID and umask it is via /etc/fstab, but whatever you specify there applies to *all* files on the file system. You cannot chown/chmod a file on a fat/ntfs/whatever partition simply because those file systems do not support that. (So basically chmod/chown on those file systems is a no-op).
Why couldn't Linux use the same paradigm for ACLs? All the native file systems would support the same ACL semantics and all the non-native ones would continue to be mapped to a single set of permissions. Or am I missing something?
___
___
If you think big enough, you'll never have to do it.
Can somebody please explain what this means?
___
___
If you think big enough, you'll never have to do it.
Me neither. But since you're talking about NT file server, the clients are windows boxes. In this case you can use Samba which supports just that. So at the local file system level you will not have this kind of flexibility. But when you export a share over samba you can specify just that.
How about allowing a group of folks the right to write to a file, but not delete it?
That's easy. Just give them write access to the file but not to the directory where the file lives. Well, the side effect of that is that they will not be able to create new files in that directory either.
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.
Ever heard of Solaris or Digital Unix or AIX? They all support ACLs too, you know.
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.
What a pile of BS! Samba can do just that. Why don't you RTFM before you spit out nonsence!
___
___
If you think big enough, you'll never have to do it.
Well, this is not what happens now and I don't see it as a problem. NTFS is sufficiently different from a Linux native file system that this kind of ACL mapping would be next to impossible. But I don't see a problem with treating NTFS as a foreign file system and mapping everything on it to a single UID & GID. This is how it works now and even without introducing ACLs into VFS this is extremely unlikely to change because M$ is not releasing the specs for NTFS.
Once again, I would be perfectly happy with having ACLs only on Linux native file systems. The foreign file systems could (and in fact should) still be treated the same way they are now. I don't see the need of mapping NT ACLs into Linux ACLs, especially if removable media is involved.
___
___
If you think big enough, you'll never have to do it.
Solaris does *not* have journalling. Unless you want to spend $10K for Veritas
___
___
If you think big enough, you'll never have to do it.
Oh, and Veritas FS does not support ACLs :-)
Which one do want more?
___
___
If you think big enough, you'll never have to do it.
That's not true. r controls whether you can read the directory (i.e. do ls in it). x controls whether you can cd into a directory or access any files in it. If both r and x are disabled, then you can neither ls a directory nor access any files in it. The Unix permission system has its problems but this is not one of them.
___
___
If you think big enough, you'll never have to do it.
Small correction: The SGID bit controls only the group ownership. The access modes will be set according to the creator's UMASK value. Either the owner or the superuser must be responsible for ensuring that the permissions of newly created files are correct.
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?
The last case just doesn't seem very convincing to me at all. There are few practical arguments for limiting, to use your example, times that people can play games on a given system.
If you don't want the games eating up server CPU cycles, don't put them on the server! Students have no "off-hours" to speak of; they tend to work all throughout the night when a project is due.
So in order to be fair to everyone, there shouldn't be time limits.
If you're concerned about IRC or tank battle using up your network bandwitdh, don't bother, because the students can easily consume much more bandwidth from the PC in their dorm room, and probably are already.
In a non-university environment, most of these just aren't issues. There will be a limit to the number of projects your company is working on via a given fileserver. People have their own workstations (or PCs) to play games on, so you don't need to worry about when they are doing that. If you're going to let them play games at all, they're certainly not going to prevent another user from getting their job done due to resource starvation.
I'm not saying there's no value to having some of these features. But I do fail to see a compelling NEED. Also, capabilities addresses some of the things you're looking for, further suggesting that ACLs are not necessary.
Sorry, but WHO NEEDS ACCESS TO A FILE IS A FUNCTION OF WHAT THE PURPOSE OF THE DATA IS!
The two are interlinked.
If you have a programmer working on more than 15 projects at a time, HE'S REALLY OVERWORKED!
Please moderate this back down. The poster obviously does not understand Unix permissions. It is NOT security through obscurity.
If you do not have access to a directory (i.e. the read and execute permissions for whatever user class you fall into -- probably "other" -- are TURNED off), YOU CAN NOT READ THE FILES IN IT. PERIOD.
And for this, Linux has capabilities. It is already possible to run Linux without a root user, except that the userland code to do so has not been written. Please see Alan Cox's posts on LKML about this topic.
agreed.
That's absurd, and demonstrates that you don't understand how Unix permissions work. The owner of a file can change the group of any file they own (to any group they are a member of, on most versions of Unix), and whether or not other users can access the file based on group ownership or everyone else. The owner of the file has a great deal of flexibility in deciding how to provide selective access to its files.
This is the problem... people who insist that ACLs are necessary either don't completely understand Unix permissions, or refuse to spend time thinking about how to solve their problem with Unix permissions. I have been a Unix System administrator for 5 years, and a syadmin of other OSes for longer than that, in a variety of environments, including several with Windows integrated into the environtment, and I have NEVER encountered a problem I couldn't solve with Unix permissions (except for one application which was ported from DOS without any regard for access control -- but here the problem is the poor design of the application, NOT Unix permissions).
A few people raised some interesting points (like appending to log files) but Unix has already proven that there are other ways to solve those problems without ACLs (like using syslog for logging, which if set up properly allows anyone to add log entries, but only the superuser to remove them).
While ACLs might have some valid uses, those applications can generally all be implemented in other ways without ACLs, especially now that the Linux kernel has capabilities (which people keep overlooking). The problem is NOT that Unix permissions are inadequate, but that people refuse to THINK about the problem they are trying to solve. ACLs are most often a cop-out for lazy system administrators. As others have pointed out, they are clunky, error prone, and complicated to administer. They leave too many opportunities for sloppy administrators to create endless streams of access lists which, in the end, no one understands, and which no one can clean up, because in so trying they will break the application they are trying to fix.
Oh, and someone is bound to point out that Unix has security holes that can allow non-priviledged users to become root and (for example) remove log entries we were trying to protect in the previous example. That may be true, but virtually ALL operating systems have such problems, including those that have ACLs like Windows NT. All OSes in common usage have weaknesses that can be exploited. Informed system administrators CAN make efforts to plug up those holes, drastically reducing the risks. This is, after all, the point of having a system administrator. If your sysadmin sucks, get a new one. But you still don't need ACLs.
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.
How about "WestlodFS"? I suggest it because i predict that your filesystem "Won't ever see the light of day."
On the other hand, "VaporFS" has a beautiful succinctness.
Decisions, decisions.
--
"Gee, thanks for wasting my time and yours.
I could name it for you -- 'TrollFS'"
now hang on a second here.
my post was hardly a waste of time. it was an honest suggestion, based on my honest opionion, with a dash of humor thrown in. just because you don't agree with me doesn't mean that you have to go sling the t-word around here.
and if you actually bothered to check my user-info, you'd see that i'm not a troll at all. perhaps offensive, blunt, rude, callous and opinionated. but hardly a troll.
and grow up. if you act that way towards anyone who has an opinion contrary to your own, your little project will fork before you manage to write, much less release, a single line of code.
--
"However, ReiserFS is broken with NFS currently..."
/net/mp3 type nfs (rw,rsize=8192,wsize=8192,soft,addr=192.168.128.25 0)
/usr/local type reiserfs (rw)
really? i sure didn't notice:
phexro!Phaktory:~$ mount -tnfs
helix:/usr/local/share/audio/mp3 on
phexro!Phaktory:~$ ssh helix mount -treiserfs
phexro@helix's password:
/dev/hdc1 on
phexro!Phaktory:~$
or are you talking about something more subtle?
--
"...there was no information in yours."
nonsense. what do you call this?
"...i predict that your filesystem 'Won't ever see the light of day.'"
sounds like information to me.
and who says that humor is a waste of time? lauging is good for you.
besides which, you completely missed the point of my post; your project is vapor. you have no code (released, anyways, which is what counts), no name, nothing to show but a bunch of buzzwords thrown together in a slashdot post. you don't even have an empty sourceforge project.
now, you sound like you might have some good ideas. and as much as good ideas are necessary, good implementations are much more necessary. you'd be much better off helping integrate your ideas into an existing project. there are so many players in the next-linux-filesystem arena that even if you do manage to make a stable release, it will probably die due to one of the other projects.
--
The problem is not reading or writing, but modifying the permissions. You are completly right that the normal access check is hidden in the kernel, but you need a standardized API to modify ACLs on all FSs.
Or maybe we mean different things by application. I would expect each ACL implementation to have it's own tools for maintaining the ACL.
Would you be happy if you had to use a special tool for every fstype? I think most people would like to set permissions from their favorite file manager (kfm/konqueror, mc, gmc ...)
Jo
Hi! I'm the infamous
Agreed! UGO does not scale when you are talking about a centralized directory with tens of thousands of users in it. Especially the G and the O parts.
I also find it funny that everytime ACLs come up, someone posts "ACLs are bad because they are too complicated and the sysadmin can shoot himself in the foot". Which is fucking hilarious attitude towards Unix, where one of the central tenent is "The Sysadmin Can Blow His Leg Off, so be careful".
--
Business. Numbers. Money. People. Computer World.
There is one that I think you can consider for this. If you go over to www.lids.org, it have LIDS system implemented into the kernel which have the ACL in there plus few other features implemented which is also useful.
I have implemented it into the Mandrake 7.2 Kernel without breaking anything and it works extremely well. So.. it is something you can consider looking into for your requirements since it is implemented into the kernel and pretty much filesystem independent as far I know of.
-- Amazing how the Internet still humms along.... -- Dispite all the flaws of Micro$oft in their software!
meaning that a private directory under /tmp is not possible without manually changing the permissions (or having all your applications be AFS aware.)
/tmp is NOT a part of AFS. You would need to be a part of the /afs heirchachy. /tmp is actually a part of whatever local fs the workstation is running.
Not true at all... as afs is a Network file system,
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).
I know it's proprietary, but it works with Linux very well:e atures
http://www.novell.com/products/nds/details.html#f
I'm looking at implementing XFS now. Should it prove stable enough, it will likely end up being what we use. Does anybody else have experience using XFS on linux on a system with a few thousand simultaneous users? (The system is going to be taking quite a beating.)
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
Perhaps my problem is that my exposure to ACLs has been primarily with NT and that can be *very* difficult to manage.
This was the primary objection that I saw on the kernel mailing list the last time it was discussed. While ACL's offer finer grain control of a system, they also make auditing much more difficult.
MOVE 'ZIG'.
and building the intranet in ASP.
At least use JSP. Then when Linux gets ACL or whatever you aren't locked in to the evil empire.
MOVE 'ZIG'.
Ideally, I need something that will work with ext3 so that the ACL information will be journaled. If you don't have a particular attachment to Linux, use Solaris. It has ACLs as well as journaling since version 7
One concept I would love to see implemented is "watchdogs." This is the ability to specify a program which should be run whenever a file or directory is accessed, opened for reads, opened for writes, written to, etc. Basically anything at the VFS level. :-)
Yeah, BeOS has that - it lets them do some really neat stuff. Unfortunately I can't deal with BeOS on a day-to-day basis without going insane, so I'd love to see Linux or FreeBSD support this.
--
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.
Please, please, please try to keep straight the differences between journaling and log-structured filesystems. There's enough confusion on this issue already, and FFS is not log-structured. AFAIK nothing being actively developed for Linux is log-structured.
I think you're right, though, about journaling vs. soft updates (of which I think Tux2's atomic update is a sub-category, though DP might disagree). Soft updates are more flexible than journaling, and - with a filesystem whose basic structures are designed to take advantage - perform better than journaling. I find it just slightly weird that there's so much focus on journaling when a superior alternative is known. I shouldn't bitch, though. For years certain people's ignorance, unwillingness to learn, and territoriality stood in the way of any progress in this area, and I for one am glad that the threat of competition has finally shaken their "hours-long fsck is OK for me" complacency. It would have been even nicer if they had responded by embracing the new entries instead of scrambling to maintain the incumbent's dominance by upgrading it just enough to stay competitive (does that remind anyone else of MS tactics?) but one can't make a purse out of a sow's ear.
Disclaimer: all views expressed are my own. If my employer took my views more seriously, their stock might not have tanked so badly.
Slashdot - News for Herds. Stuff that Splatters.
While incredibly evil, i would think your best bet to allow different groups of people different kinds of permissions would be seperate directory structures with huge ammounts of hard-linking. Probably rather evil, but its a suggestion :P
One concept I would love to see implemented is "watchdogs." This is the ability to specify a program which should be run whenever a file or directory is accessed, opened for reads, opened for writes, written to, etc. Basically anything at the VFS level. :-)
Logging is trivial to implement.
ACLs are trivial to implement. The program looks at the user and can indicate (via return code) whether to permit access.
Compression and encryption are relatively easy to implement, if you also retain some state information betweens calls.
Even virtual files and directories can be implemented. This could be used to implement things like "ftp" and "http" mounts.
There's a lot of similarities with "user space" file systems, and that concept might be preferred now.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Fat/vfat file systems don't have the concept of an "owner," but NTFS does. Ideally this ownership information (and ACL permissions) will be retained even if someone sticks an NTFS-formatted zip disk into a Linux box.
The problem is that there's no obvious connection between NTFS ownerships and the user/group of the host Linux system. If you trust root to identify the mapping you leave the system open to attack by anyone with local root access. This would prevent Linux from being adopted in some environments.
A similar problem occurs with the network file systems. You want to avoid the biggest headache in NFS, the ability of someone with local root access to impersonate any other user. It's possible, but it requires the system distinguish between network and local user ids.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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
Maybe it's my limited experience with ACLs, but while I can see why ACLs are an attractive feature, I've rarely found a situation where they can be used without making administration complex. Unix file permissions may be simple, but they are also dead easy to manage.
In Solaris, the OS uses standard Unix permissions, with the possibility of optionally using ACLs (I don't know about other Unices). This gives admins the options of using ACLs for a few limited cases - anything more, and it's probably better to setup a special Unix group of something.
Perhaps my problem is that my exposure to ACLs has been primarily with NT and that can be *very* difficult to manage.
Gee, thanks for wasting my time and yours.
I could name it for you -- "TrollFS"
- - - - -
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 stand by my original post; there was no information in yours.
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
XPFS or CPFS
(cross platform FS)
Good suggestion! Thanks!
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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.
we actually had to implement a simple ACL for ext2 in an operating systems class i took at columbia. it wasn't all that hard (50-60hrs for a couple undergrads). as far as i can tell though, it would not be trivial to do it kernel-wide. without some major re-architecturing, you would really have to implement the ACL for each filesystem seperately.
--
Smokey the Bear says, "Strip mining prevents forest fires!"
Linux 2.4 w/ XFS really is a marvel. Even though its is supposedly beta quality, it has been rock solid for me (two weeks of benchmarking it against BFS ;) and there don't seem to be any real issues using it on Linux. You have to switch to LILO (remember that?) and you lose some as of yet unimplemented features (group quotas) but it is very solid. My benchmarks put the Linux version as faster than BFS and ReiserFS, and feature-wise it has attributes (too bad Linux won't take full advantage of them) and all the other feature seem to have made it to the Linux port unmolested.
A deep unwavering belief is a sure sign you're missing something...
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...
Eros has some great white papers
What is a Capability, Anyway?
Where Capabilities Come From
Comparing ACLs and Capabilities
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?
I asked Alan Cox about this and he said that capabilities were pretty much unrecognized by the wider comunity, and thus there were no need for ACLs. But IMHO, capabilties aren't nearly as clean as ACLs (rwxs + capabilities can be confusing, ACLS put everything neatly in one permission system).
There's a large portion of (well, dickheads, really) who think any idea implemented in NT doesn't belong in Linux. This ignored the fact that the Trusted flavors of various closed source Unixes and VMS have had the same system for years. And that Microsoft, whilst not having the worlds best business practices, can occassionally make good OS deesign decisions
(and even sometimes be the best tool for the job, but that's OT).
I'm not sure what Linus would say, but I'd like to echo those sentiments exactly. There's no reason I, nor any service, ever need to run as root.
* Why does my mail server need a small program with permissions to install a rootkit in
* Why can't I delegate the task of adding and deleting users to a minion without worrying they will corrupt the filesystem?
* When I want full access to a file, managers to have read and execute access, employees to have read access, and nobody else to have any access at all, why can't I just DO IT?
Rwxs wasn't designed for security. ACLs even fit in better with the Unix philosophy of giving users and processes only the permissions they need to use the system and no more.
Sudo is a hack.
Use the SMB PAM module with Apache to authenticate form the NT server
Use Halycon Software of Chilisoft to deploy your ASP app on Linux.
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.
From the ACL mailing list, it looks like they're working on getting ACLs into the mainstream kernel - at least, it's talked about :) Another feature that I'd really like to see though, is file access auditing - the ability to log when particular files are opened read, opened write, actually have data written to them, etc. The closest thing that I've found to this is fam/imon by SGI; but this would require some coding to let it be used for this purpose.
*sigh*... long night.
I felt obliged to point out that Daniel Phillips, of the Tux2 file system, has now created indexed searched through directories (similar conceptually to btrees, but not quite as fast).
Check out the mailing list archives here
For directories with over 20000 files, the results are 10 times faster with the indexed searching. The ratio gets better with more than that. So I guess ext2 won't have to wait long for btrees. If Tux2 happens sometime soon then it will really rock ! Great job Daniel !
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.
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
Reiserfs + knfsd support in Kernel 2.4.x is VERY CLOSE to working properly. If I recall correctly, one of their initial problems was due to a general NFS bug that crashed even some ext2 setups. Now they are getting the final kinks out of it, and it should be ready Real Soon Now(tm).
TOPS-10 had a cool way to do ACLs. Basically, if an access failed, the kernel would ask the FILMON daemon if the access should be allowed. The FILMON daemon looked for a file, ACCESS.USR, which contained the rules to decide who had access. The beauty of this scheme is that no filesystem changes are required, and the kernel changes should be pretty minor, too. Furthermore, in many ways, this is BETTER than access lists, because it better matches how people think of their directories. E.g., if I follow a convention that all my files are private except those named *.pub, it is much easier to write one rule that applies to all of my files, than to remember to put the rigth ACLs on each file. Newly created files will tend to have the right protection, because I will follow my convention. I don't need to remember each time to set the ACL. Also with this scheme, there is no need to rewrite every utility to deal with ACLs.
Even if you do end up on NT, you can still run the Win32 port of Apache and use PHP or Jakarta and JSP if you want to keep alive the chance of moving back to a *nix platform at some point in the future.
I'd presume he means that you can't export a ReiserFS filesystem as an NFS share.
Vintage computer games and RPG books available. Email me if you're interested.
Vintage computer games and RPG books available. Email me if you're interested.
Vintage computer games and RPG books available. Email me if you're interested.
I dont understand how you morons can be discouraging these people from doing something they want to do. Even if it doesn't become useful, IT'S WHAT THEY WANT TO DO.
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.
I'm so glad that you posted this. As a decade-long NetWare guy I've never been able to understand why UNIX permissions seem so limited. For so long I've simply thought that my lack of understanding was keeping me from implementing UNIX permissions the way that I want to.
It's just so *easy* in NetWare to lay out filesystem (and NDS) access across multiple groups, users, etc. I mean is it too much to ask to be able to assign RO access to a directory to one group and RW to a different group? There's probably a way to do this, but it doesn't readily present itself to the novice.
the no
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?
(I hate it when that happens. I put in everything but the conclusion.)
IMHO, access lists are only useful to allow you to fill in the little checkbox on government/military procurement forms "access lists? (y/n)" with a "y"
Only way you're gonna get Linux into government/military stuff is to have access lists. Full stop. Therefore, ACLs are very useful (vital, actually) as a patch to some standard filesystem, just so you can check the little box. As to merging them into the kernel, forget it. They really accomplish nothing, and just get in the way.
--
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
ACLs (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...).
An engineer who ran for Congress. http://herbrobinson.us
Think before you act; more importantly, think before you tell people that what they've been working on for years is worthless.
ALL YOUR BASE ARE BELONG TO US!
SIG: HUP
Typically data in a file system is no a good way of data management. Stick it in a RDMS such as Oracle or Postgresel etc. Security in File systems is weak compared with something like Lotus Notes/Domino which uses Public/Private keys and ACLs so deep they make NT look whimpy . All of these solutions are available under Linux. Once in a database you can sort it, parse it etc much more easily. In terms of Code management stick to something like CVS. Anthony
If I remember my UNIX history (which I may not---this is all pretty much before I was born :), the first UNIX was created as a stripped-down Multics. Multics had a very thorough file and hardware security control.
So Multics was stripped down to UNIX, and people have been fighting an uphill battle ever since to reintroduce a lot of the security features lost in that translation. I've been wondering for years whether it would be possible for someone to resurrect the relevant features from Multics... Since it hasn't happened, I guess it isn't possible.
Oh, well...
My company, largely a Microsoft-based shop, is wanting to build a new intranet. I am totally *nix dependent, and up till now, I've run into only a few cross-platform issues with projects focused mainly on our internet offerings. But, an intranet is very different from an internet site. It's meant to be a central site for the company that ties together other systems and information, which in our case currently reside on mostly Microsoft-based solutions.
I really WANT to deploy our intranet on a Linux platform, but its proving tough and is possibly not feasible. One of the biggest obstacles is Linux' lack of ACL support. Our NT-based staff wants a web-based front-end to their fileserver that loses none of the functionality of NT's security. To do it, I planned to move the fileserver to Linux as well, which they were willing to do. But, it turns out I'm just not able to match the security configurability of NT, and my superiors won't stand for anything less.
If Linux had ACL support, perhaps I could find a way to pull it off. I'm still researching some of the ACL projects available, but my situation looks grim. What really disappoints me about this is that I'm having to admit that Linux is not ideal for our situation, and I'll likely end up on IIS and building the intranet in ASP. Ugh.
I guess Microsoft has done its dirty work well.
See, and that's at the heart of the design issue. Many of the "limited" permissions you might construct with ACLs turn out to be equivalent to "root" permissions anyway; having ACLs gives you a false sense of security. Delegation of specific privileges generally only works reliably with very careful programmatic permission checking. That's why UNIX has setuid programs.
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.
Looks like the Multics ACL setup from the 60's, though I'm not sure it as well thought out yet. See http://www.multicians.org for more information on ACL development in the 60's.
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...