Re: File regular expression matching in KAuth
Re: File regular expression matching in KAuth
- Subject: Re: File regular expression matching in KAuth
- From: evaluador evaluador <email@hidden>
- Date: Tue, 23 Jun 2009 09:57:28 +0200
Ok, I'll give it a try. Thank you Mike.
2009/6/22 Michael Smith
<email@hidden>
ACLs are traditionally applied to file objects, not names.
Kauth operates on file objects that may have an arbitrary set of names; at the time a file operation is performed and authorised neither the name by which the object was looked up nor any of the arbitrary set of other names it might be looked up by are known for certain. Files are routinely looked up by the file/volume ID tuple without a name at all.
You're going to have to work out how you want to make this association between file names and file object stick, after which pulling in PCRE or similar will be relatively straightforward.
= Mike
On Jun 22, 2009, at 8:47 AM, evaluador evaluador wrote:
I am implementing ACLs with KAuth in the file operation scope, and I would like to use regular expressions without having to implement they myself. The configuration for the ACLs need to match, for example /etc/p*....
2009/6/22 Michael Smith
<email@hidden>
On Jun 22, 2009, at 12:02 AM, evaluador evaluador wrote:
That would work from user space, but I need to go through kernel space with KAuth...
Kauth does not do what you're asking for, and the sandbox stuff is kernel-space.
Perhaps if you explained what you were actually trying to do, we could offer more help.
= Mike
2009/6/19 Jacques Vidrine
<email@hidden>
On Jun 19, 2009, at 9:47 AM, Todd Heberlein wrote:
You can accomplish your example by using Sandbox in Leopard and later releases. It provides a flexible mechanism for defining what operating system resources a process may or may not obtain. Unfortunately, that mechanism is not API, and may change from release to release.
I though Apple's sandbox was a "voluntary" thing, where the application chooses to sandbox itself, and if it doesn't call the sandbox APIs itself, then no sandboxing. (???)
That’s correct, but the sandbox is inherited. Therefore, a parent can force its child into the sandbox.
$ sandbox-exec -p '(version 1) (allow default) (deny file-read* file-write* (regex #"^/private/etc/p"))' zsh
So it looks like you are putting zsh in a sandbox, and then wc just inherits that sandbox when it is launched from zsh. Is that correct?
Yep.
Cheers,
--
Jacques
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (
email@hidden)
This email sent to
email@hidden
--
Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price -- Samuel Johnson
--
The lyf so short, the craft so long to lerne -- Chaucer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden