Codestin Search App

Rich access control lists

Posted Oct 21, 2015 7:57 UTC (Wed) by mbunkus (subscriber, #87248)
Parent article: Rich access control lists

Jon, you've written that "This behavior conflicts with POSIX, which requires that any "supplemental security mechanisms" be disabled for new files." I'm not sure I understand what you mean, exactly.

POSIX ACLs already have default ACLs on directories which are applied to all new entries created within such a directory. Doesn't this fall under the same term of "supplemental security mechanisms"? And what does "supplemental" mean in the first place? Is a directory's sticky bit deemed to be a base security mechanism or would that not qualify and be "summplemental" as well?

Near the end you mention Samba which I've been meaning to ask about, too. At the moment Samba stores NT(FS)-specific ACLs in extended attributes (Make sure your backup software saves those, too!). Are the RichACL a strict superset of NT(FS) ACLs so that Samba could switch to using them instead of extended attributes for kernels and file systems that support RichACLs? And how would RichACLs interact with NFSv4 or later – would they be transmitted or would they be stripped down to what NFSv4 ACLs can do?

And while we're on the topic of extended attributes: does anyone know of work going into making NFS support extended attributes?

I'm looking at this specificially as an admin of various networks in which Linux and Windows clients access the same file servers via NFS and CIFS. I'd appreciate any insight into what's on the horizon wrt. ACLs, extended attributes, NFS etc.

to post comments

Rich access control lists

Posted Oct 21, 2015 11:28 UTC (Wed) by jlayton (subscriber, #31672) [Link] (46 responses)

Yes, the samba devs are the main ones that have been clamouring for RichACLs. Allowing better windows semantics is one of the primary use-cases for them. Their current form is good enough for samba to make use of them.

For NFSv4, they'd be translated into what NFSv4 ACLs can do. We do have to follow the protocol, after all. FWIW, knfsd currently translates NFSv4 ACLs into POSIX acls and back, but that's necessarily lossy. This should allow for much better semantics (though there are still some open questions about how this will work when idmapping fails).

There is a draft proposal to add xattr support to NFSv4:

https://tools.ietf.org/html/draft-ietf-nfsv4-xattrs-01

...and I think there are some patches that add this support, though it's unlikely they'll be merged until it's a little farther along.

Rich access control lists

Posted Oct 21, 2015 12:02 UTC (Wed) by mbunkus (subscriber, #87248) [Link] (1 responses)

Thank you very much. That's exactly what I wanted to know.

Rich access control lists

Posted Oct 21, 2015 17:23 UTC (Wed) by bfields (subscriber, #19510) [Link]

Note that draft only covers what on Linux are the "user.*" extended attributes: "This document restricts the allowed namespaces to user-managed metadata only, in order to prevent the development of non-interoperable implementations. It requires that the attribute key/value MUST not be interpreted by the NFS clients and servers."

So for example the special system.posix_acl_{access,default} xattrs used to manage posix acls still wouldn't be exposed over NFS.

Rich access control lists

Posted Oct 21, 2015 15:23 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (17 responses)

> though there are still some open questions about how this will work when idmapping fails

Isn't this a general problem with DENY-type access control lists? It's relatively easy to force a client to prove that it *should* have access with a cryptographic challenge authentication protocol. But when you have user- or group-specific DENY entries in the ACL, you're asking the client to prove that it *shouldn't* have access, which isn't in the client's interest.

In particular, dropping a group membership should never *increase* a program's permissions.

Rich access control lists

Posted Oct 21, 2015 16:47 UTC (Wed) by jra (subscriber, #55261) [Link] (16 responses)

That presumes the client is in charge of the access token. On modern auth systems the client can't modify its own token (it's cryptographically protected), the server keeps it on the clients behalf.

Rich access control lists

Posted Oct 21, 2015 19:09 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (15 responses)

I assume you're referring to the ability to drop group membership. Yes, the server can assign groups to each authenticated user and not let the client modify the set of groups, but unless you're assuming a closed set of user accounts, what prevents the client from using an account other than the one which was denied permission? Is there a "guest" account? Can one request the creation of a new account (or otherwise gain control over an account) which isn't a member of the group?

Even if the process can't remove groups itself, an administrator can, and it's counter-intuitive that removing a user from a group might increase that user's privileges.

Whitelists are better than blacklists. Attempting to enumerate all the bad accounts or groups is poor security practice.

Rich access control lists

Posted Oct 21, 2015 20:18 UTC (Wed) by fandingo (guest, #67019) [Link] (14 responses)

> it's counter-intuitive that removing a user from a group might increase that user's privileges.

It's only counter-intuitive because that's what you're used to. If you learned on systems with NFSv4-style ACLs, this wouldn't be confusing. We just need to get used to the idea of negative permissions.

> Whitelists are better than blacklists. Attempting to enumerate all the bad accounts or groups is poor security practice.

Sure, I guess, but nobody is talking about using allow *or* deny lists exclusively. They're talking about being able to mix them to apply complex policies. I imagine one place where allow and deny will be routinely combined is with daemons. They get an allow for append-only write access, and explicit denies for read, delete, and general write accesses. That's a completely reasonable policy.

Rich access control lists

Posted Oct 21, 2015 22:42 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (13 responses)

> It's only counter-intuitive because that's what you're used to. If you learned on systems with NFSv4-style ACLs, this wouldn't be confusing.

No, it's counter-intuitive because of how groups work in the real world. Being a member of a group is a privilege, not a burden. Being accepted into a group has positive connotations; rejection is negative.

Obviously one can learn to use either system, but whether or not it's deemed intuitive shouldn't depend on which system you had prior experience with. It should be based on what someone with no prior experience with ACLs would expect.

> I imagine one place where allow and deny will be routinely combined is with daemons. They get an allow for append-only write access, and explicit denies for read, delete, and general write accesses. That's a completely reasonable policy.

The reasonable version is a "default deny" policy. Don't just deny access to the daemons, deny access to everyone by default (as POSIX ACLs and standard permissions would), and grant the daemons append-only access. If other users or groups should have read, delete, or general write access, grant it to them specifically, not as a default.

Rich access control lists

Posted Oct 21, 2015 22:56 UTC (Wed) by fandingo (guest, #67019) [Link] (3 responses)

> No, it's counter-intuitive because of how groups work in the real world. Being a member of a group is a privilege, not a burden. Being accepted into a group has positive connotations; rejection is negative.

What about prison inmates? What about people on no-fly lists? Groups have negative connotations and restrict behavior all the time.

Rich access control lists

Posted Oct 22, 2015 17:50 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (1 responses)

> What about prison inmates? What about people on no-fly lists?

Personally, I tend to think of those from the opposite (positive) point of view. The group of members of society in good standing; the group of people granted the privilege of flying. (Which should be the same as the first group, but that's a whole other discussion...)

Obviously any particular set of rules can be implemented either way. The problem mainly arises when you add new users to the system. In a pure whitelist scenario, you only have to decide what the new user *should* have access to. Anything you don't grant access to is off-limits, which is a safe default. If you build your system around DENY rules then you also have to make sure the new user gets added to the appropriate blacklists, or they'll have more access than you intended.

Rich access control lists

Posted Oct 22, 2015 18:26 UTC (Thu) by fandingo (guest, #67019) [Link]

> Personally, I tend to think of those from the opposite (positive) point of view. The group of members of society in good standing; the group of people granted the privilege of flying. (Which should be the same as the first group, but that's a whole other discussion...)

What a coincidently self-serving stance, but it's still a tortured viewpoint that's incorrect. It simply doesn't comport with reality. The government does not maintain a list of people authorized to fly, so there's no group there. They do maintain list for no-fly and mistakenly-no-fly people. Same thing for inmates; there's no list of free civilians, but there are lists (per jurisdiction) of those incarcerated. To get a list of free people, you need to derive that from the difference between the census and those in prison. The implementation dictates POV.

> Obviously any particular set of rules can be implemented either way. The problem mainly arises when you add new users to the system. In a pure whitelist scenario, you only have to decide what the new user *should* have access to. Anything you don't grant access to is off-limits, which is a safe default. If you build your system around DENY rules then you also have to make sure the new user gets added to the appropriate blacklists, or they'll have more access than you intended.

Meh, that's what administrative user-management tools are for. Let the software handle it.

Rich access control lists

Posted Oct 30, 2015 17:17 UTC (Fri) by Wol (subscriber, #4433) [Link]

> > Being accepted into a group has positive connotations; rejection is negative.

> What about prison inmates? What about people on no-fly lists? Groups have negative connotations and restrict behavior all the time.

You missed that sentence of the OP ... Prison inmates aren't ACCEPTED, they're PLACED. Likewise the no-fly. You can split groups into two types, the ones you JOIN, and the ones that other people PUT you in. Yes, the latter are normally places you'd rather not be.

But if you treat ACLs as the former type of group, then it makes everything a lot simpler.

Cheers,
Wol

Rich access control lists

Posted Oct 22, 2015 17:36 UTC (Thu) by eternaleye (guest, #67051) [Link] (2 responses)

> Being a member of a group is a privilege, not a burden. Being accepted into a group has positive connotations; rejection is negative.

I'll note that even on classic mode bits, a group can restrict access. See above on how "the other permission is not even consulted if user or group match" - because of that, u=rw,g=,o=r is an entirely valid permission that denies read only for a specific group.

Rich access control lists

Posted Oct 22, 2015 18:18 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (1 responses)

> I'll note that even on classic mode bits, a group can restrict access.

Right, and I don't consider that intuitive either. The effective permissions should be a bitwise-OR of the applicable fields, not simply the first match.

Rich access control lists

Posted Oct 24, 2015 17:20 UTC (Sat) by jubal (subscriber, #67202) [Link]

I guess you wouldn't like pam_access either.

Rich access control lists

Posted Oct 22, 2015 18:55 UTC (Thu) by idra (guest, #36289) [Link] (4 responses)

>> It's only counter-intuitive because that's what you're used to. If you learned on systems with NFSv4-style ACLs, this wouldn't be confusing.
> No, it's counter-intuitive because of how groups work in the real world. Being a member of a group is a privilege, not a burden. Being accepted into a group has positive connotations; rejection is negative.

This is not the reason why negative ACLs are bad, they are bad because they do not fail safe.
If an ACL is accidentally dropped in a Posix like system you lose access, with DENY ACLs if a DENY ACL is dropped then you gain access, which is a much worse failure mode.

Pure Windows semantics are even worse, and *are* counterintuitive, because not only they provide DENY ACLs, they are also *ordered*. And many admins do not understand the complex relationship that arises when you DENY *after* an ALLOW. Reason why the GUI clients in Windows do actually re-order ACLs so that all DENY instructions always come first, and they hide the fact order matters for the NT Kernel.

Of course hilarity ensues if you intentionally ordered an ALLOW ACL before a DENY ACL with a CLI tool and then someone just add a completely unrelated instruction via the GUI. Your careful ACL breaks as the gUI reorders everything; but at least in that case it fails safe because you end up denying access to a larger set, not allowing more access.

> The reasonable version is a "default deny" policy. Don't just deny access to the daemons, deny access to everyone by default (as POSIX ACLs and standard permissions would), and grant the daemons append-only access. If other users or groups should have read, delete, or general write access, grant it to them specifically, not as a default.

In some rare cases it may be simpler to add exceptions (all users but Joe should be able to read this file), but usually the need of an exception is a sympthom of a much deeper broken system/process elsewhere.

Rich access control lists

Posted Oct 22, 2015 20:10 UTC (Thu) by fandingo (guest, #67019) [Link] (3 responses)

> This is not the reason why negative ACLs are bad, they are bad because they do not fail safe.
If an ACL is accidentally dropped in a Posix like system you lose access, with DENY ACLs if a DENY ACL is dropped then you gain access, which is a much worse failure mode.

This is entirely incorrect and undermines your entire point. ACL resolution order is an explicit feature of Linux ACLs (and traditional POSIX mode bits). Let's say I'm using traditional ACLs, and a file has permissions r-----rw-. It's owned by me, and the group doesn't matter. This is a negative policy! I am not allowed to write to this file, but others are. If the user "ACL is accidently dropped" to, say, change ownership (ACLs are a combination of a user/group object and mode bits), I end up with more permissions than I'm supposed to. This is specifically mentioned in the article.

> And many admins do not understand the complex relationship that arises when you DENY *after* an ALLOW.

How do I put this nicely? I don't want design limitations because some people are too stupid to learn the tools. That's their problem. Don't mount with the Richacl option if you don't know what you're doing.

> Reason why the GUI clients in Windows do actually re-order ACLs so that all DENY instructions always come first, and they hide the fact order matters for the NT Kernel.

I don't see why this matters at all. It's an implementation issue that the software completely handles for you, and it sounds like a good decision.

> Pure Windows semantics are even worse, and *are* counterintuitive, because not only they provide DENY ACLs, they are also *ordered*. And many admins do not understand the complex relationship that arises when you DENY *after* an ALLOW. Reason why the GUI clients in Windows do actually re-order ACLs so that all DENY instructions always come first, and they hide the fact order matters for the NT Kernel.

I don't understand what you're getting at. Back in the early NT days, yes, there were tooling problems, but those have been long corrected. Maybe you can be more specific, but this has been fixed for ages. There are some low-level APIs that allow insertion of ACLs without resolving the overall policy, but they're counter-recommended and proper versions have been around for a long time. But, hey, nothing like a Linux forum criticizing Microsoft with severely outdated information.

> In some rare cases it may be simpler to add exceptions (all users but Joe should be able to read this file), but usually the need of an exception is a sympthom of a much deeper broken system/process elsewhere.

I agree with this statement. I haven't once advocated for broad use of denial policies. Instead, I'm arguing that the ACL implementation needs to allow this expressiveness because there are legitimate situations where it's needed.

Rich access control lists

Posted Oct 25, 2015 1:44 UTC (Sun) by idra (guest, #36289) [Link] (2 responses)

> This is entirely incorrect and undermines your entire point. ACL resolution order is an explicit feature of Linux ACLs (and traditional POSIX mode bits). Let's say I'm using traditional ACLs, and a file has permissions r-----rw-. It's owned by me, and the group doesn't matter. This is a negative policy! I am not allowed to write to this file, but others are.

Sorry man but you are very confused. First of all with as Posix permissions and not Posix ACLs, that said the default is no access ---, you have been given read access by turning on the r bit. Perimissions cannot be accidentally dropped so that case does not apply to the basix posix permissions. In any case if that bit were dropped you'd lose read access, whic is consistent with what I said.

> How do I put this nicely? I don't want design limitations because some people are too stupid to learn the tools. That's their problem. Don't mount with the Richacl option if you don't know what you're doing.

Tools are as good as they are usable by *normal* people. A car only a F1 drvier can use is ... how can I put it nicely ... useless to everyone but the 20 odd F1 driver on the planet, which is to say uselss.

Now RichACLs are not *that* hard, but my experience tells me that ACL systems the include ordered deny policy are a double-edged sword, and the balance between complexity and usefulness is wrongly tilted. All this said I need RichACLs to be able to reach compatibility with Windows ACLs so I'll take them as they come.

> I don't understand what you're getting at.

Sadly obvious.

> Back in the early NT days, yes, there were tooling problems, but those have been long corrected. Maybe you can be more specific, but this has been fixed for ages. There are some low-level APIs that allow insertion of ACLs without resolving the overall policy, but they're counter-recommended and proper versions have been around for a long time. But, hey, nothing like a Linux forum criticizing Microsoft with severely outdated information.

Look, those issues were not bugs that got fixed and are there no more, they are fundamental usability issues that are due to the semantics chosen. They just got "handled" by adjustment done by the GUI tools. Now there is no criticizing here *at all* (that's all in your mind pal), but only making people unfamiliar with these semantics that the *same* problems will now be found in systems used by Linux admins. They can be solved the same way, by forcing the tools to reorder the ACIs and massahe the ACLs, but afaik the tools do not do that today.

Rich access control lists

Posted Oct 25, 2015 4:30 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

> that said the default is no access ---

No, the default is 0777. You set umask to take bits away.

Rich access control lists

Posted Oct 25, 2015 9:06 UTC (Sun) by paulj (subscriber, #341) [Link]

Bizarre, why use order-significant ACLs if to make them usable tools must then - all, consistently! - normalise the order somewhat?

Rich access control lists

Posted Oct 29, 2015 14:56 UTC (Thu) by fest3er (guest, #60379) [Link]

Sounds like a firewall. First apply blacklists (those individuals and groups who are to be denied access at all times). Next apply whitelists (those individuals and groups always allowed access). Then apply mixed allow/deny rules that may allow access or may deny access. Finally, if access hasn't already been allowed or denied, deny it. Easy concept. Non-trivial implementation.

Rich access control lists

Posted Oct 21, 2015 17:49 UTC (Wed) by drag (guest, #31333) [Link] (25 responses)

I would be very happy to see better compatible ACLs with Windows and NFSv4.

In Windows-world their extended ACLs are used as of a matter of course. In Linux-land the the POSIX ACLs are almost never used. I expect that people that use them the most are Samba users. Next biggest is likely NFSv4 users...

I think this may be a big win for Linux in general.

Rich access control lists

Posted Oct 21, 2015 20:11 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (24 responses)

> In Windows-world their extended ACLs are used as of a matter of course.
So much that consumer versions of Windows actually ship with something that resembles Unix permissions.

> In Linux-land the the POSIX ACLs are almost never used.
Which is really telling. Do we actually _need_ extended ACLs used anywhere except for fileservers?

Rich access control lists

Posted Oct 21, 2015 20:25 UTC (Wed) by fandingo (guest, #67019) [Link] (23 responses)

> Which is really telling. Do we actually _need_ extended ACLs used anywhere except for fileservers?

The problem with Linux ACLs is that they don't allow novel permission schemes. It's still just RWX. The issue that Richacl is trying to solve is much broader than multiple RWX policies.

Here's the simplest general use-case for Richacls: every daemon that writes to a log file. W, whether through POSIX or Linux ACLs, is simply too crude for secure logging. That's a major reason why so much stuff needlessly goes through syslog just to end up on the local file system. So, yeah, I expect the append-only Richacl to be used a lot.

Rich access control lists

Posted Oct 21, 2015 21:01 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> The problem with Linux ACLs is that they don't allow novel permission schemes.
Do we _need_ novel permission schemes? They are pretty much useless for anything except fileservers. And fileservers are not that popular anymore.

Rich access control lists

Posted Oct 21, 2015 21:27 UTC (Wed) by fandingo (guest, #67019) [Link] (3 responses)

Ummm, yes we do. I provided a really simple example of where this is really needed. You're just saying the same thing that caused my initial reply.

Rich access control lists

Posted Oct 21, 2015 22:35 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Except that there's simply no guarantee that a large write will be atomic. If many writers are appending into one file, they _will_ get corruption eventually. And anyway, rsyslog or journald have already pretty much solved this problem.

I worked with Windows ACLs extensively. That's the reason why I hate complicated permission systems.

Rich access control lists

Posted Oct 21, 2015 22:57 UTC (Wed) by fandingo (guest, #67019) [Link]

You're assuming multiple writers, but I don't know why. This has nothing to do with ACLs. It's an IO synchronization problem.

Rich access control lists

Posted Oct 29, 2015 14:13 UTC (Thu) by Wol (subscriber, #4433) [Link]

> I worked with Windows ACLs extensively. That's the reason why I hate complicated permission systems.

As others have said, it's just so complicated ...

And I know I've said it before, but Pr1mos just had read, write, use. For files or directories. So that makes six different permissions. And using them was simple - if your user was explicitly specified, that was what you got. If you weren't explicitly named, but your groups were, those permissions were added together. And if neither your user, nor a group you were in, was specified, you just got the default permissions. Very simple, very easy to understand.

Cheers,
Wol

Rich access control lists

Posted Oct 21, 2015 21:16 UTC (Wed) by dlang (guest, #313) [Link] (17 responses)

> That's a major reason why so much stuff needlessly goes through syslog just to end up on the local file system.

you are ignoring the fact that if things are written to go through syslog, even if they end up on the local filesystem in many/most cases, it's far nicer when you do want to do more than just write to the local disk.

having to poll local filesystems for changes to log files and then scrape them is a very poor thing to do.

Rich access control lists

Posted Oct 21, 2015 21:16 UTC (Wed) by dlang (guest, #313) [Link] (16 responses)

... besides, aren't we being told that the solution to all logging is to write to the systemd journal anyway?

Rich access control lists

Posted Oct 21, 2015 21:24 UTC (Wed) by fandingo (guest, #67019) [Link] (15 responses)

I'm not getting into another journal discussion with you. Anyways, there's plenty of programs that log data that doesn't need to or can't go through syslog. Applications running in containers are a prime example that typically lack syslog capabilities.

Not everything is centralized either. Additionally, you'd use this exact same append-only policy on the files that syslog does write, making your point moot. I don't know about you, but I don't run my applications or centralized syslog systems on a file server.

Rich access control lists

Posted Oct 21, 2015 21:31 UTC (Wed) by dlang (guest, #313) [Link] (14 responses)

There's no reason why syslog support can't be used in containers, either from running syslog inside the container, or having the host syslog daemon create /dev/log inside the container to capture the logs

Rich access control lists

Posted Oct 21, 2015 22:02 UTC (Wed) by fandingo (guest, #67019) [Link] (13 responses)

Jeez. I'm not arguing that it's technically impossible. The idea of running an unrelated logging daemon in a container is antithetical to the idea of containers. Passing through a socket isn't always appealing either. That being said, you're missing the point. Currently, if you want to securely write log messages to a daemon you need a different trusted daemon to do that, but if you're just logging to local files, I don't need that diversion. I just need a security mechanism that doesn't allow a compromised application to wipe out its log files; I don't need a logging daemon. In this example, a logging daemon is nothing more than a side-effect of an insufficient permission model.

Rich access control lists

Posted Oct 21, 2015 22:38 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

A compromised application can just spam the log files with 2Mb zero-filled data pages. It will scramble other writers and make analysis difficult.

And there are much better ways to do it already, anyway.

Do you have less contrived examples? Preferably not involving a "mainframe shared among faculty and students" textbook scenario that is pretty much irrelevant right now.

Rich access control lists

Posted Oct 21, 2015 23:03 UTC (Wed) by fandingo (guest, #67019) [Link] (11 responses)

You think containers are a contrived example? There are plenty of situations that need WORM semantics where append-only is important. Any transaction processing system that appends to a file would benefit from that security.

> A compromised application can just spam the log files with 2Mb zero-filled data pages. It will scramble other writers and make analysis difficult.

That's better than a 0B file that was maliciously truncated...

Rich access control lists

Posted Oct 21, 2015 23:19 UTC (Wed) by dlang (guest, #313) [Link] (3 responses)

If you trust the kernel and permissions to protect the file from being truncated once you have a malicious actor taking over your binary, you have a lot more trust than I do.

Anything important like that sort of log data, I want off on a separate machine.

Rich access control lists

Posted Oct 22, 2015 0:04 UTC (Thu) by fandingo (guest, #67019) [Link] (2 responses)

> Anything important like that sort of log data, I want off on a separate machine.

I already addressed this in a previous comment.

>> Additionally, you'd use this exact same append-only policy on the files that syslog does write, making your point moot.

Wherever that data hits disk, it's advantageous to be able to restrict to `append_data`, even when that writing is happening on a separate system.

Rich access control lists

Posted Oct 22, 2015 0:09 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

> Wherever that data hits disk, it's advantageous to be able to restrict to `append_data`, even when that writing is happening on a separate system.

advantageous, yes

but worth how much in the face of the added complications, bugs and performance hit?

Also, to make use of this, the applications are going to have to be modified in linux-only ways. Some apps won't care, but others try to be cross platform, so this sort of churn won't be welcome.

Rich access control lists

Posted Oct 22, 2015 0:56 UTC (Thu) by fandingo (guest, #67019) [Link]

> but worth how much in the face of the added complications, bugs and performance hit?

It's worth 42. I don't know how to answer the obviously loaded, rhetorical question. You'll need to offer data about performance implications before I'll get into that topic; it's just FUD otherwise.

> Also, to make use of this, the applications are going to have to be modified in linux-only ways. Some apps won't care, but others try to be cross platform, so this sort of churn won't be welcome.

For the most part, this isn't something that applications will interact with at all. (I suppose beyond EACCESS when there is a violation, but they have to deal with that anyways.) It will be handled just like SELinux policy: The Linux distribution writes and maintains it.

There is specialized software that may need to interact with Richacl specifically, but I just don't see it being a major problem. The only places where it may cause a problem is when a project is sloppy with it's open(2) mode flags, which should be tightened regardless of Richacl. If a piece of software is diligent, writing a policy for that software package isn't any challenge.

Rich access control lists

Posted Oct 22, 2015 0:17 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> You think containers are a contrived example? There are plenty of situations that need WORM semantics where append-only is important. Any transaction processing system that appends to a file would benefit from that security.
If you want real WORM for auditing purposes then file permissions are not enough.

Append-only mode also does not guarantee atomicity, so I'm curious to see the actual systems that depend on it. I'm not aware of anything non-trivial.

Rich access control lists

Posted Oct 22, 2015 0:27 UTC (Thu) by smckay (guest, #103253) [Link] (1 responses)

Does HDFS count? As appending is the only kind of writing you can do. ;)

Rich access control lists

Posted Oct 22, 2015 0:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

As far as I know, no HDFS implementations depend on filesystem-level append-only permissions.

Rich access control lists

Posted Oct 22, 2015 1:13 UTC (Thu) by fandingo (guest, #67019) [Link] (3 responses)

I neither said nor implied it did. IO synchronization is a separate problem. Perhaps down the road, they can add additional Richacl types (unsigned int leaves a lot of available flags) for open(2) modes like O_SYNC (and other associated syscalls) to allow Richacl policy to require or prohibit that option.

> so I'm curious to see the actual systems that depend on it.

I'm not sure any piece of software itself could "depend" on it. From the software's perspective, it's just eliminating extraneous syscalls and mode flags. It's the software distribution's (or perhaps the adventurous sys admin's) job to write and distribute a policy. The policy separation and delegation to distributions is same as SELinux.

Rich access control lists

Posted Oct 22, 2015 1:30 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

And to guarantee that the entries are also semantically correct, perhaps we can add another permission to attach an XML (or even ASN.1) schemas to files?

Of course, some people might also forbid any file activity on Sundays, so we need a special permission for that as well.

Rich access control lists

Posted Oct 22, 2015 1:50 UTC (Thu) by fandingo (guest, #67019) [Link] (1 responses)

Sure, if you want to do that, although some file systems have xattr length limitations. I'd treat ACLs the same as LSMs: Pick anyone you want (and stack them if you like and support is implemented). The data will be stored in xattrs defined by that ACL module, and a file system feature flag can be used to force (or indicate if a bypass kernel cmdline / config option is set) a kernel to use that ACL module.

Nonetheless, I doubt you'd have many people in such a scheme. But, let's dial it back from absurdity.

Rich access control lists

Posted Oct 22, 2015 22:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

No. Complex LSMs proved to be a total failure - NOBODY understands how SELinux works, so on most systems it just sits idly and eats resources.

At least with modebits I can understand what's happening immediately. With Windows ACLs you can't do that - you have to carefully evaluate the rules, keeping their order in mind. POSIX ACLs are ok-ish, they at least play nicely with the regular Unix permissions.

And your examples are so far extremely poor. If you need to constrain a daemon to use only O_APPEND - then write an LSM module for that. No need at all to rape file permissions. And if you are doing it over NFS then get a proper rsyslog, for FSM's sake.

So what are other examples, apart from the contrived O_APPEND?

Rich access control lists

Posted Oct 21, 2015 14:58 UTC (Wed) by agruen (subscriber, #6613) [Link]

There are two kinds of inheritance: the first defines the permissions that files and directories inherit from their parent directory when created, the equivalent to Default POSIX ACLs. Those don't conflict with POSIX.

The second mechanism, Automatic Inheritance, extends the first: ACEs which are inherited from the parent are marked as such; when the parent permissions are modified, the inherited permissions change as well. This is implemented by walking the directory tree and updating all ACLs, in user-space.

Automatic Inheritance works well enough as long as the inherited permissions are not modified. POSIX syscalls that create files or directories have a mode parameter which defines the maximum permissions that may be granted, and appling that mode to the inherited ACL counts as a modification, however. The effect is that Automatic Inheritance is immediately stopped at create time.

Both CIFS and NFSv4 have "create without a create mode" operations though; they can emulate those by doing normal creates and re-enabling Automatic Inheritance. That's the best we can do at the moment.