On Mon, May 25, 2009 at 7:12 PM, Gwynne Raskind wrote:
> On May 25, 2009, at 6:52 PM, Michael Ash wrote:
>>
>> The authentication stuff is pertinent, because the AEWP is an example
>> of an API which works by having an unprivileged user process
>> communicate with a privileged process that does th
> It does? Last I checked, AEWP() used a temp file on disk to pass its
> AuthorizationRef to the child process. Pipes, anyone?
Hah. I wonder what temp directory it uses?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin re
On May 25, 2009, at 6:52 PM, Michael Ash wrote:
The authentication stuff is pertinent, because the AEWP is an example
of an API which works by having an unprivileged user process
communicate with a privileged process that does the work. A technique
which allows you to compromise a process which u
On Mon, May 25, 2009 at 6:18 PM, Kyle Sluder wrote:
> On Mon, May 25, 2009 at 3:08 PM, Michael Ash wrote:
>> Not at all. It doesn't change my point one whit. If A can command the
>> privileged process to do something nasty, then C can do it too.
>> (Possibly by breaking into A by one of the many
On Mon, May 25, 2009 at 3:08 PM, Michael Ash wrote:
> Not at all. It doesn't change my point one whit. If A can command the
> privileged process to do something nasty, then C can do it too.
> (Possibly by breaking into A by one of the many mechanisms available
> and forcing it to make an evil requ
On Mon, May 25, 2009 at 3:50 PM, Jeremy Pereira wrote:
>
> On 25 May 2009, at 20:23, Michael Ash wrote:
>
>> On Sun, May 24, 2009 at 7:57 PM, Greg Guerin wrote:
>>>
>>> Michael Ash wrote:
>>>
Malevolent process C fails.
>>>
>>> Or maybe malevolent process C works because it's running with th
On 25 May 2009, at 20:23, Michael Ash wrote:
On Sun, May 24, 2009 at 7:57 PM, Greg Guerin
wrote:
Michael Ash wrote:
Malevolent process C fails.
Or maybe malevolent process C works because it's running with the
same uid
as unprivileged process A. The sticky-bit on a directory only
pr
On Sun, May 24, 2009 at 7:57 PM, Greg Guerin wrote:
> Michael Ash wrote:
>
>> Malevolent process C fails.
>
> Or maybe malevolent process C works because it's running with the same uid
> as unprivileged process A. The sticky-bit on a directory only prevents one
> uid from interfering with another
Michael Ash wrote:
Malevolent process C fails.
Or maybe malevolent process C works because it's running with the
same uid as unprivileged process A. The sticky-bit on a directory
only prevents one uid from interfering with another uid's files. It
has no effect if the uids of the proce
On Sun, May 24, 2009 at 3:18 PM, Michael Ash wrote:
> /tmp has a special permissions bit set called the sticky bit. When set
> on directories, the sticky bit modifies the standard UNIX permissions
> model and makes it so that the directory's contents can only be
> deleted or renamed by the owner o
On Sun, May 24, 2009 at 12:52 PM, Kyle Sluder wrote:
> 1. Non-privileged process A running as user Alice creates a file
> called /tmp/ipc.
> 2. A signals to privileged process B, running as root, that the file exists.
> 3. Malevolent process C, running as user Eve, notices the file,
> unlinks it (
On Sun, May 24, 2009 at 11:28 AM, Dave Keck wrote:
> I debated whether I should mention my technique thinking someone might
> bring up this precise vulnerability. :)
It is possible to use /tmp safely, but you have to be very careful.
Just like when doing anything sensitive on the filesystem.
> M
> 1. Non-privileged process A running as user Alice creates a file
> called /tmp/ipc.
> 2. A signals to privileged process B, running as root, that the file exists.
> 3. Malevolent process C, running as user Eve, notices the file,
> unlinks it (which it can do due to the permissions on /tmp) and
>
On Sun, May 24, 2009 at 9:52 AM, Kyle Sluder wrote:
> If you *must* use /tmp for some reason (not linking
> against Foundation, etc.) use FSFindFolder.
Sorry, wasn't clear here. I meant "If you can't use
NSTemporaryDirectory", not "If you *must* use /tmp".
--Kyle Sluder
On Sun, May 24, 2009 at 5:58 AM, Dave Keck wrote:
> I use /tmp. Works great for me - I use it to save temporary files that
> another privileged process then moves to a permanent location. Launchd
> uses it too, along with a host of other things.
Please don't just toss things in /tmp. Launchd doe
Richard Frith-Macdonald wrote:
What you want is user specific and application specific I presume
(ie you want to store the data your your application, and for the
person who is running the application). I guess it's not really
temporary (or you wouldn't need a fixed path), but is actually
I use /tmp. Works great for me - I use it to save temporary files that
another privileged process then moves to a permanent location. Launchd
uses it too, along with a host of other things.
But yeah, where you put your temporary files really depends on the
context and who needs to see the them.
D
On 23 May 2009, at 11:43, Nick Rogers wrote:
Hi,
NSTemporaryDirectory(), returns something like /var/temp/we/weOIDM
+mck
Whereas I want to store files at a place with a fixed path.
So where should I save temp files? and how can I get that path
programatically everytime?
What
On 23 May 2009, at 12:43, Nick Rogers wrote:
Hi,
NSTemporaryDirectory(), returns something like /var/temp/we/weOIDM
+mck
Whereas I want to store files at a place with a fixed path.
So where should I save temp files? and how can I get that path
programatically everytime?
Use t
Hi,
NSTemporaryDirectory(), returns something like /var/temp/we/weOIDM
+mck
Whereas I want to store files at a place with a fixed path.
So where should I save temp files? and how can I get that path
programatically everytime?
Thanks,
Nick
___
20 matches
Mail list logo
