Slashdot Mirror

Unix user/group setups can do what you need. For example, say I have three applications. App1, App2, and App3. User1 needs access to App1 and App3, but not App2. User 2 needs access to App1 and App2 but not App3. User3 needs access to App3 but not App1 or App2.

Create three groups. Say, app1, app2, app3. Change the group for each app to it's group and set the execute permissions to only allow owner and group (750). Add user1 into the groups app1 and app3. Add user2 into app1 and app2. Add user3 into app3.

A single user can be in multiple groups.

Same can be done with data files. I do this all the time at work with samba shares.

Also, all modern Linux distros support full ACLs. At least on ext3, xfs, and jfs.

Comparing Vista to SunOS is sooooooooooo disingenuous...

educate yourself

You've got a bunch of points (many of which are valid to one degree or another) but I'm only going to respond to one.

It [NT4] had full support for ACLs in the filesystem. Linux got that in, what, 2000? Does it even work with the standard filesystems?

ACL's are a filesystem feature, not an OS feature. NTFS has them, FAT and FAT32 do not. Ext2 does not have ACL's, though hooks were left for ACL's from the beginning and support can be patched into 2.4 and 2.6 kernels for Ext2 and Ext3. AFS (Andrew File System), which is the original king of ACL's, could be used on Linux in 1998. ReiserFS has them (don't know for how long). SGI's XFS is the same (I think this was pretty recent).

I've been using ACLs with UFS2 (the default FS) on FreeBSD for a couple of years, but I've not seen them in common use on Linux.

Evidently, people don't miss them, because the option has been available to Linux users about as long as NTFS has been on the scene. I would hazard a guess that ACL's aren't the "make or break" feature for most people's filesystem choice.

Now, I'm not going to seriously rain on your parade as the point of this argument seems to boil down to: NTFS is a great filesystem. I agree. NTFS is some sweet technology that works real nice in the here and now. But it isn't the only game in town for high performance journaling file systems (with ACL's no less). The fact that people don't really seek out ACL's on linux is simply that ogw permissions are so well understood by so many unix admins, and most of the time, ogw permissions are good enough.

Regards,
Ross

They did something similar with an even more important technology: file type metadata.

You know what I love? When an Open Source project implements something, it's just another feature, but when a commercial company puts some marketing force behind it they're being innovative.

Linux has had xattrs for some time. See http://acl.bestbits.at/. They probably got most of the code for free somewhere else.

If you really want to get your panties in a bunch, NTFS has supported a very advanced form of metadata (via streams) since it's inception. Moreover, HFS had metadata that was removed for OS X :-)

It's not a new or innovative concept at all. Sorry.

You're absolutely right. The goes for all *nix platforms, too. Lack of good ACL support is one reason my superiors would never consider rolling out tons of Linux servers at work.

At my office, we currently have 3 Linux servers that I administer and it's damn embarrassing every time I have to explain to somebody the limitations of *nix permissions. Believe me, in a mostly Microsoft environment, it comes up more often than you'd think.

If some of the major distributions would start adding better support for POSIX ACL's, maybe we wouldn't be in this mess. Unfortunately, as it stands, Microsoft has *nix beat in this area, hands down.

Why reinvent the wheel? AFAICS, there already is ACL support for ext2/ext3 and even nfs.

You seem to be suggesting that Novell should implement ACLs into Linux. ACLs are already present in the 2.6 series kernels, and available as a kernel patch for 2.4. They're for ext2, ext3, jfs, and xfs filesystems.

While the functionality is present, the problem is that so far no distribution has decided to implement them across the system.

Extended Attributes and ACLs for Linux

I just want to throw in my 2 cents and say that the Linux deals Novell has made in the past year are real head-slappers.

You know, "Dang! why didn't I think of that?"

For years, Novell has been looking at the Windows as an internet application server platform and for a while, they wanted Netware to compete. Finally, they found a way to make it happen - big time. They also bring to Linux all their years of experience with Netware, Groupwise and file and user security and directory services, so I even expect other projects like Samba and Filesystem ACLs will benefit too.

Dust off the red markers, boys, the 'N' is back in town.

The SMB protocol and NTFS are two distinctly different things. On Win2K with NTFS, you have security rights associated with the filesystem (i.e. what you can do to a file or folder on that machine even logged in locally), and share rights associated with the share (i.e. what you can do to a file or folder over the network). Many admins prefer to leave the share rights alone (so the "Everyone" group has full access), and then restrict per user access at the filesystem. This way someone who normally has no rights to a particular file/folder can't bypass the restriction by logging into the server locally.

Samba can pretty much duplicate an NT4 box as far as shares go, but to get NTFS style ACLs in Linux you need the 2.6 kernel and the various utils.

Solaris has lots of feature that are beginning to exist in linux (may exist, but not widely implemented) and the bsd's. One example dynamic reconfiguration. Getting some ram errors? Cool, swap it out. (while you're running) Real access controls work, i.e.: "setfacl -m user:mongo:r-- test"; the user mongo has specific (read only) access to the file test. yesm you can patch your kernel, but it's in solaris by default. Solaris containers are pretty cool too: think userspace linux w/ the expense of multiple kernels crossed w/ openmosix crossed w/ linux-HA.

Solaris may go a way. Solaris may become a legacy OS. There are some *really* cool things in solaris that do not exist in linux yet, though, and if they keep up the R&D, by the time mainsream linux has them, then they will have other really cool stuff. Does that mean that people will pay lots of $$ for them when they can install freebsd or linux for free? I don't know. I think that a lot of the stuff in there *is* worth it, and if the trend in the linux market place goes the way redhat wants it to, where you're going to be spending $300 for a copy of the os/server anyway, then I definitely think solaris is worth a look.

You can do ACL's with linux. There's just very little point to them. Sure, windows "supports" ACL's, but show me where it's actually being used. In reality, ACL's require the admin to know what he's doing securitywise, and let's face it: most don't.

The unix-style permissions scheme can be fully automated in the software install process. Admins can be blisfully ignorant of it and still have it work. I think it also speaks volumes about the effectiveness of permissions that most windows users run as Administrator (or a user account with comparable power), and most linux users run in a regular user account.

Here's a big one, a large plus in my book, that Solaris has had forever: POSIX ACLs and Extended attributes. And here's an place with examples showhing why this is a Good Thing. Hooray!

$ setfacl -h
usage:
setfacl [-r] -f aclfile file ...
setfacl [-r] -d acl_entries file ...
setfacl [-r] -m acl_entries file ...
setfacl [-r] -s acl_entries file ...

Also available for linux

Red Hat Linux 9 Technical Changes (or when the RELEASE-NOTES are just not enough) by Dax.Kelson@GuruLabs.com
Copyright 2003 Guru Labs, L.C.
Intro Over the past eight years or so, I've been excited each time a new version of Red Hat Linux gets released. During the past few years, people have even been writing reviews of each release. As a general rule, I've been dissatisfied by the superficialities, inaccuracies, and irrelevancies in the reviews often times performed by someone who does not have intimate knowledge of Red Hat Linux. A systems administrator needs an in-depth review that covers relative to the previous release:

• Architectural & behavioral changes
• Installer changes
• Changes to included software packages

Normally, with each new release of Red Hat Linux, someone here at Guru Labs combs through it looking for the above changes to update the Guru Labs Linux courses. This time it was my turn, and I decided to simultaneously write a technical review for the system administrators out there. I hope that the results are satisfactory.

Abbreviation notes:
RHL = Red Hat Linux
RH = Red Hat Inc.
Architectural & behavioral changes There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant. Kernel 2.4.20-8 The kernel in RHL8.0 was based on the 2.4.18 kernel. Despite the name, the RHL 2.4.20-8 kernel is based on 2.4.20 plus bug fixes identified up through 2.4.21-pre4-ac4. During the past couple years, the RHL kernels have included back ported functionality from development kernels that has proven stable. The new RHL9 kernel is no exception. Major changes since RHL8.0 include:

• Addition of Native POSIX Thread Library (NPTL) for standards based threading support with impressive performance. This is definitely a nice addition, however, I anticipate that sys admins who add patches on-top-of the RHL kernel from 3rd party (UML, FreeSWAN, etc) sources will have a more difficult time getting the patches to apply and work cleanly. Presumably when the 2.6 kernel comes out, the divergence of the RHL kernel will drop substantially.
• • Certain applications using the old LinuxThreads API in a certain manner may no longer work (was that vague enough?)
  • In particular if using Java, update to the latest version from Sun at:
  • http://java.sun.com/j2se/1.4.1/download.html
  • The WIN32 API translation software, WINE, suffers from this problem. Proper fixes are in the works, however, workarounds exist.
  • Installing and running Oracle 9i R2 has major issues since it includes two different older embedded Java JVMs that don't work with NPTL. The solution is stick with RHL8.0 or the officially supported Red Hat Linux AS edition.

ACPI support appeared in a beta (as well as in a 8.0 beta), but was removed for the final shipping kernel.

Filesystem ACL and EA support appeared in the betas, but was pulled for the final shipping kernel. I was really looking forward to ACLs and EAs support in RHL (Solaris had support since 2.5.1), maybe an errata kernel will re-add the feature.

• To see what software specifically supports

• Architectural & behavioral changes
• Installer changes
• Changes to included software packages

Normally, with each new release of Red Hat Linux, someone here at Guru Labs combs through it looking for the above changes to update the Guru Labs Linux courses. This time it was my turn, and I decided to simultaneously write a technical review for the system administrators out there. I hope that the results are satisfactory.

Abbreviation notes:
RHL = Red Hat Linux
RH = Red Hat Inc.
Architectural & behavioral changes There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant. Kernel 2.4.20-8 The kernel in RHL8.0 was based on the 2.4.18 kernel. Despite the name, the RHL 2.4.20-8 kernel is based on 2.4.20 plus bug fixes identified up through 2.4.21-pre4-ac4. During the past couple years, the RHL kernels have included back ported functionality from development kernels that has proven stable. The new RHL9 kernel is no exception. Major changes since RHL8.0 include:

• Addition of Native POSIX Thread Library (NPTL) for standards based threading support with impressive performance. This is definitely a nice addition, however, I anticipate that sys admins who add patches on-top-of the RHL kernel from 3rd party (UML, FreeSWAN, etc) sources will have a more difficult time getting the patches to apply and work cleanly. Presumably when the 2.6 kernel comes out, the divergence of the RHL kernel will drop substantially.
• • Certain applications using the old LinuxThreads API in a certain manner may no longer work (was that vague enough?)
  • In particular if using Java, update to the latest version from Sun at:
  • http://java.sun.com/j2se/1.4.1/download.html
  • The WIN32 API translation software, WINE, suffers from this problem. Proper fixes are in the works, however, workarounds exist.
  • Installing and running Oracle 9i R2 has major issues since it includes two different older embedded Java JVMs that don't work with NPTL. The solution is stick with RHL8.0 or the officially supported Red Hat Linux AS edition.

ACPI support appeared in a beta (as well as in a 8.0 beta), but was removed for the final shipping kernel.

Filesystem ACL and EA support appeared in the betas, but was pulled for the final shipping kernel. I was really looking forward to ACLs and EAs support in RHL (Solaris had support since 2.5.1), maybe an errata kernel will re-add the feature.

• To see what software specifically supports ACLs and EA

Mine is bigger than yours :)

Linux XFS: 9 exabytes

Also supports extended attributes.

I agree with most of your post, but I'll bite on semantics because I have some links to dump...

"While various linux filesystems support ACLs, no one is using them yet."

Nobody? Then how come Samba has had support for them in the server (with kernel support) and the client since version 2.2.0?

For filemanagers, what is it that exporer.exe can do that nautilus or konqueror can't? I mean except freeze up when you unplug the network cable... I'm puzzled.

One thing they are useful for is if you are replacing NT file servers with Samba servers. If you don't use ACLs (either XFS or the EA/ACL patch with ext2/3) then your Windows users who connect to your Samba shares don't get all the fine-grained permission control to which they are accustomed; Samba fakes it. Combine this with winbind and you end up with almost a perfect drop-in replacement for your NT file servers, and you don't have to manage those users separately. Sah-weet.

And this doesn't even touch on the nice sharing and permissions options MS gives us.
You mean ACLs? Yes, Windows has a nice set of file permissions--classically one of its advantages over Linux.
Linux, however, now has an even more robust set of ACLs which come with GRSecurity, and let's not forget POSIX ACL's which are almost finished.
Linux still has all of its security advantages over NT though, such as not using IIS, Outlook*.*, IE, Commerce Server, MS SQL, et al, all of which have had some big nasties recently. True, so have some Linux/Unix daemons, but far less frequently and you have to wait about half an hout to two days for a fix rather than three weeks to a 18 months on into infinity for a patch from Microsoft.

NT does have advantages, but don't EVEN bring up security if you are trying to defend NT. That's a sure-fire way to discredit the platform.

I know you're all too lazy to read the entire release notes, so jump directly to the source of these tools. RedHat's release notes say:

This beta contains a kernel providing EA and ACL support for the ext3 filesystem based on the patches and user-level tools from http://acl.bestbits.at/

So, check them out directly. They have more information than the RELEASE-NOTES, and some useful examples.

With ext3 filesystem?

http://acl.bestbits.at/

With xfs filesystem?

http://oss.sgi.com/projects/xfs/

Just add samba 2.2.3a that has acl support and stir. What did I need that NT server for again?

Storing metadata about files in the file system? Could be useful...

And of course it's already been done...

Actually, support seems to be coming along quite nicely for ext2. Patches are available here. I've been using the acl implementation (just a special case of Extended Attributes) for about two years now on a production server. Works beautifully for finer-grained file permissions. Also, the project leader (Andreas Gruenbacher) seems to communicate frequently with both the Samba team (to allow modification of Linux ACLs from an NT client) and the XFS team (to ensure that the API is common across implementations.)

That's called an ACL and mature OSes which are designed with security in mind have them.

Hey Mr. Troll, guess what, I agree with you...

Actually, you can use it, with ext2 *and* ext3. The ACL group implemented ACLs as extended attributes, that can also be used for metadata (icons, mime types, whatever):

Check out the ACL guys homepage for more details.

The XFS command line utilities seem to be less effective than the Bestbits patches & utils, and the Samba 2.2.1a support seems to be a bit off with its handling of recursive descents and inheritance. To be fair on both counts, I'm still learning the file system, and the problems could be all mine.

I'd thought about ReiserFS, but I really need those ACLs.

Just some thoughts. Any errors are all mine. Please feel free to correct. I have no pride.

There a couple of projects which add meta data to Linux.

The first can be found here. This project adds ACLs and extended attributes to the ext2 filesystem.

There is also the XFS filesystem. This features extended attributes, ACLs and journaling.

I have also heard that extended attributes and ACLs are planned to be supported in the 2.6 kernel. I hope this is true because I think extended attributes can be used to make the Linux Desktop Enviroments alot better.

I really wish someone would include BFS-style attributes in an Open Source file system

It's called XFS :-)

XFS supports extended attributes just like BeFS. no wonder, since BeFS is based, at least in part, on ideas originated in XFS. You will need some userland tools to set extended attributes and probably a modified tar if you want to preserve attributes inside archives. The web page on Access Control Lists and Extended Attributes might also prove useful. Now, combined with fam & imon , which provide (i)node monitoring you have everything except indexed searching, all in Open Source (imon is actually a kernel patch that adds node monitoring at the VFS layer)

-adnans

Did you read the story, you know the words at the top of the page? This story is about Samba using TrustedBSD's ACLs. Linus' Linux doesn't even support ACLs without flaky, third-party patches. The Extended Attributes and Access Control Lists for Linux FAQ says:



Q10 When will Posix ACLs be part of the kernel?

There are multiple steps to getting ACLs into the kernel. The first step, which we are heavily debating on the mailing lists right now, is how to design the system call interface for extended attributes and ACLs. The next step will be to include the extended attribute code into the kernel, or create even better extended attribute code for that purpose. Then, on top of that, we can include ACLs for the ext2 and ext3 filesystems. Other filesystems such as XFS be able to support ACLs directly, without needing extended attributes.

Yes, it is WELL supported in both 2.2 and 2.4. Check out http://acl.bestbits.at/.

And, yes, it is supported in Samba 2.2.

zsazsa

Unification of Windows 2000 and Windows NT Access control lists (ACLs) with UNIX Access control lists. Allow Windows clients to directly manipulate UNIX Access control entries as though they were Windows ACLs.

greetings, eMBee.
--

* Security in *nix sucks

I'm hoping that you mean Linux security, since this isn't true at all for many other UNIX OSes. For Linux, I think the security is good enough for what it is, when it is used right. The problem is that many applications and servers don't use it right. POSIX.1e-style capabilities (see Linux-privs - POSIX.1e Capabilities for Linux, http://www.sourceforge.net/projects/linux-privs/) are probably the answer. A more legitimate qualm with the *nix model is that it is coarse-grained. I think at least a handful of UNIX OS's have responded with support for Access Control Lists, which provide more fine-grained file access (see Extended Attributes and Access Control Lists for Linux, http://acl.bestbits.at).

* X Windows sucks

The X Window System catches a lot of criticism, some of it well-deserved. Most of it, however, is purely inane. It works very well, all things considered. Most of the technological deficiencies (i.e., mainly rendering technology) are resolved with modern extensions. Naturally, there are better ways to do it. We could have a much better architecture. But that's all hindsight. What we're looking at is not a transition that would be based on advantages, but on disadvantages. Until the limitations of the X Window System outstrip the convenience of using what's already there and well-supported, we have X. But Xfree86 is good enough for now. There might be alternatives in the future (Berlin, http://www.berlin-consortium.org/).

* the xterm gui-cli interface sucks

I'm stumped. You determine that you need the CLI for some task while you're in the GUI. What better interface can you get than actually getting the CLI in the GUI? (Which is what Xterm does for you.)

* all the shells suck ...

They seem to have everything I need and want, and more. Filename completion (with cycling through potential matches), redirection (especially with file descriptors, as in bash), good line editing, conditions and looping, scripting, ... Maybe I'm thinking inside the box, but I can't think of anything that I've needed to do that hasn't been made easy (if not trivial) by some shell.

* file system in *nix sucks

Well, it's not as if every UNIX uses the same file system. I don't understand this claim, really. Are you arguing against heirarchical file systems or against the file systems themselves?

* netscape in *nix sucks

It performs very well for me, as do Mozilla (http://www.mozilla.org) and Konqueror (Konqueuror). There's a lot of hype around Opera (Opera), but I've never tried it. There are particular deficiencies in each of these, of course, but most of them perform the task of web browsing well enough. Not to forget, of course, Lynx (Lynx).

Anyway, there are legitimate issues. Standardized package management on Linux would be nice, ACLs/Capabilities would be nice... And I'm always up for a new Window Manager or Desktop Environment. I use Sawfish/GNOME (Sawfish, http://sawmill.sourceforge.net/; GNOME, http://www.gnome.org/). But, eh, keep complaining: anything that gets me new toys to play with can't be too bad.

One of my biggest gripes with Linux is that I can only assign directory or file access based on the user, group, world model. NT allows you to specify lists of specific users.

Take a look at the implementation of POSIX Access Control Lists for Linux. It's a kernel patch that puts standardized ACLs into the Linux kernel (2.2 and 2.4) to allow setting very specific permissions for seperate files and directories. From the page:

Access Control Lists (ACLs) support more fine-grained permissions. Arbitrary users and groups can be granted or denied access in addition to the three traditional classes of users.

This is probably very similar to the permissions on an NT system, and some other commercial Unix systems also implement those POSIX ACLs.

I'm a little confused. While I've looked for details on how to verify that a system is B1 compliant, I only seem to find vauge references.

I don't see the practical difference between a system that's B1 compliant and one where ACLs are added (1) (2) and all accounts including root are severly restricted -- and both of these security measures avaiable under Linux.

I realize that verification testing is done on a per-installation basis, so many of the details will be specific to that installation. ...yet, all security is specific to the tasks and installation, so this doesn't clear up anything.

The general goals including many specific "the system shall" type directives, should be readily available...but where?

Tools like LIDS under Linux and other kernel patches to handle ACLs seem to do the job...so what's missing?

So, like it or not, some people really do need the NT ACL stuff.

...or some flavor of ACL stuff, e.g. the stuff that was being worked on as a POSIX draft, or various implementations based on various POSIX drafts (Solaris and Digital UNIX both have POSIX-draft-like ACLs, and other UNIXes might as well - there's a project to implement them for Linux as well), or non-POSIX-style ACLs such as appear on HP-UX.

Check out LIDS - the Linux Intrusion Detetion System. You can lock everyone (including root) out of doing certain things, like killing certain processes, inserting/removing modules, changing files, modifying firewall rules, and a lot of other stuff. Plus it's a lot easier for people to write stuff like this when the kernel is publicly available.

BTW, once a cracker has a command prompt on a unix system, that's all they've got. They'll be running as the UID of whatever daemon they comprimised, but they still won't have root (unless the daemon was (stupidly) running as root). Any sysadmin without massive head trauma will not allow a normal user to do root-things. Then again, with some of the setuid root binaries I've seen, I wonder if the head wounds interfere with typing :). But that's stupidity, which won't ever be preventable. All that can be done is enabling and encouraging intelligence.

As for fine tuned granularity, groups work fine for most people, but if they aren't your style, there are Access Control List patches available. Check out this one. It's all about choices.
--