The only thing I can think of, and this would be a far out stretch, is
you make a launchd item that monitors /Applications. Anyone trying to
copy anything from that directory to any other directory gets stopped
and deleted.

I am not sure how you would script it, but you can make launchd watch
/Applications and the second anything is copied you can trigger a
script. Do note that what we previously discussed with MCX can limit
users from running any kind of application outside of /Applications.

Using MCX, you can prohibit running apps from certain locations, but if a
client has read rights, they can copy the app files.
What are you trying to accomplish? If you want to prevent piracy, I don't
believe that's your organization's responsibility (of course, I'm not an IP
lawyer, so take that with an appropriate grain of salt).

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

No, not trying to prevent piracy, just wondering. I already asked this question and got the same answer, but then symlinks came to mind and I thought I'd take a shot in the dark.

Sent from my iPhone

Tom,

Yes, true, and I've been limiting application launches from anywhere outside of /Applications. To be completely honest, one of my two ideas (well, the only idea beside the symlink one) was creating a launchd item that did just that. I didn't know how feasible that was, though, so I didn't mention it. Now that I have some intellectual support on that idea, I'm gonna start testing it. This is a big deal at our site, since the school doesn't wanna eat the $30K it just spent buying every kid a flash drive. (Against two admins' judgement, btw, mine included.)

Good weekend to all.

Darn. Here I'd always hoped that some funky set of ACLs could prevent the problem. We have a problem where students move applications onto their desktops when trying to put it on their Dock (and then we get complains that the app is not installed, or that users (inexplicably) can not log into network accounts with a .app on the desktop.)

If you are serious about writing a launchd item, and especially if your running all Leopard, there is a python application called crankd that can install hooks into system events (like filesystem activity, network transitions, and such) and call your code when it happens. I don't know a lot about it, but http://code.google.com/p/pymacadmin/ is a place to start looking. I think it might be easier to work with than launchd.

If you do come up with something, I'd appreciate it if you'd share.

Cheers,
Clinton Blackmore

Thanks for that. I'm going to start work on it after the weekend.
Expect email asking for help :)

Sent from my iPhone

I have search and destroy scripts that search out and delete certain file systems, by file extension. I suppose you could modify my scripts to search the path of the user's desktop and have it remove anything with .app as the extension. If they don't have write access to /Applications they can't trash them. You could also use Unix permissions to make their desktop read only, so they would be forced to save things in their ~/Documents but I can see that causing issues perhaps. Like Safari for example, by default wants to download files to the user's desktop.

We have had this problem as well, and I could never come up with a working feasible solution that wouldn't confuse or cause issues with end users using their laptops.

But don't your scripts run at intervals?What if a user copies an app
to his flash drive and unmounts it before your script ran?

Sent from my iPhone

That is where launchd would kick in. It monitors the folder and then when whatever action is taking place it then executes what you tell it to do so. You could have it check every 30 seconds, or however you set it up in ARD. Once it is triggered the script can run, but yes it will take time to run and if it takes too long and the user ejects their usb thumb drive then it will become moot.

I just think it seems like a lot of hassle for very little pay off.

Hi All,

what you need is KeyServer, i use a KeyServer to monitor and control licenses and if you KEY and application then it cannot be run without a connection to the keyserver so if an application is copied to a pen drive and taken else where it will never run.

Criss

Criss Myers
Senior Customer Support Analyst (Mac Services)
Apple Certified Technical Coordinator v10.5
LIS Business Support Team
Library 301
University of Central Lancashire
Preston PR1 2HE
Ex 5054
01772 895054

Do you have to be connected to this key server for it to work? Like if I go off campus with my laptop are all my 'keyed' applications no longer going to run?

Thanks

If you have "keyed" applications they work when you can talk to the keyserver. Options for when the keyserver is not available are to allow the app to run and just meter the usage and report update when it can talk again, or to deny the app to run. You also have the option to allow the user to "check-out" a license or seat before leaving the network of which you can predefine how long that check out lasts.

Keyserver client runs as service.

I think that is all the options, but there may be more options. I'm not our keyserver guru, but we use it here.

Craig Ernst
UW-Eau Claire
(715) 836-3639

Sent from my iPhone

On Feb 17, 2009, at 2:06 PM, "Thomas Larkin" <tlarki at kckps.org<mailto:tlarki at kckps.org>> wrote:

Do you have to be connected to this key server for it to work? Like if I go off campus with my laptop are all my 'keyed' applications no longer going to run?

Thanks

Yes that pretty much it, you can join the keyserver to your directory system and grant access based on groups, computers, locations etc or even give priority at set times of the day. I dont use any of these functions i just use it to monitor software usage, but if youneed to control the use of apps its very good

Criss

Criss Myers
Senior Customer Support Analyst (Mac Services)
Apple Certified Technical Coordinator v10.5
LIS Business Support Team
Library 301
University of Central Lancashire
Preston PR1 2HE
Ex 5054
01772 895054

I started seeing if I could figure out how to do this with crankd
(which, while it has potential, is still in its infancy and not well
documented), and, after getting something together that didn't work, I
posted to the pymacadmin site. The thread is here: http://groups.google.com/group/pymacadmin/browse_thread/thread/2c077fcd1ed7361f

The last response I got is very worthwhile, so I am sharing it here:

Funny you should post that. The same user posted the same solution to my question on the MacNN forums yesterday. I'm testing it out today.

Funny you should post that. The same user posted the same solution
to my question on the MacNN forums yesterday. I’m testing it out
today.

Fascinating. Please let us know how well it works. (Did you write a
script that can be deployed by Casper to do it?)

The author who suggested the technique just added that:

Trying to catch this by watching filesystem events is the
wrong
approach, you will always be chasing after things. The better
approach, at least for users who aren't going to resort to the command
line, is to prevent the Finder from copying the apps. There is an easy
trick to this: put a folder inside the .app bundles (next to
"Contents") that starts with "A" and don't give users read or execute
permissions on that folder (I would go with root:wheel:0000). When the
Finder enumerates the files it is going to copy it will run into that
and stop.

I did forget to mention that there is one dark side to doing this: it
breaks application signing. Apple has only started to use this, so
unless you are using MCX to restrict what applications a user can use
this will have no effect at the moment (this needs to be reviewed when
10.6 comes out). You can still work with it, you just have to make
sure that the application signing happens with your modification in
place. For a lab image this should be very doable.

--
Karl Kuehn

On 18-Feb-09, at 10:33 AM, Jeff Strauss wrote:

Funny you should post that. The same user posted the same solution
to my question on the MacNN forums yesterday. I’m testing it out
today.


On 2/18/09 9:28 AM, "Clinton Blackmore" <clinton.blackmore at westwind.ab.ca
> wrote:

I started seeing if I could figure out how to do this with crankd
(which, while it has potential, is still in its infancy and not well
documented), and, after getting something together that didn't work, I
posted to the pymacadmin site. The thread is here: http://groups.google.com/group/pymacadmin/browse_thread/thread/2c077fcd1ed7361f

The last response I got is very worthwhile, so I am sharing it here:


On Feb 17, 2009, at 9:54 PM, Clinton Blackmore wrote:

> We have some problems when users copy a .app folder to their
desktop
> when trying to put it on their dock; specifically, this prevents
> network users from logging in. Also, I'm aware of another system
> administrator who wants to prevents students from copying .apps to
> their USB drives.

Trying to catch this by watching filesystem events is the
wrong
approach, you will always be chasing after things. The better
approach, at least for users who aren't going to resort to the command
line, is to prevent the Finder from copying the apps. There is an easy
trick to this: put a folder inside the .app bundles (next to
"Contents") that starts with "A" and don't give users read or execute
permissions on that folder (I would go with root:wheel:0000). When the
Finder enumerates the files it is going to copy it will run into that
and stop.

This is easy to circumvent by either copying things by
opening
the .app bundle, or by working on the command line, but it does put up
a big enough barrier that most users won't be able to cross it.

--
Karl Kuehn
lark... at softhome.net


On 14-Feb-09, at 3:16 PM, Jeff Strauss wrote:

> Thanks for that. I'm going to start work on it after the weekend.
> Expect email asking for help :)
>
> Sent from my iPhone
>
> On Feb 14, 2009, at 2:17 PM, "clinton.blackmore" <clinton.blackmore at westwind.ab.ca
>> wrote:
>
>> Darn. Here I'd always hoped that some funky set of ACLs could
>> prevent the problem. We have a problem where students move
>> applications onto their desktops when trying to put it on their
Dock
>> (and then we get complains that the app is not installed, or that
>> users (inexplicably) can not log into network accounts with a .app
>> on the desktop.)
>>
>> If you are serious about writing a launchd item, and especially if
>> your running all Leopard, there is a python application called
>> crankd that can install hooks into system events (like filesystem
>> activity, network transitions, and such) and call your code when it
>> happens. I don't know a lot about it, but http://code.google.com/p/pymacadmin/
>> is a place to start looking. I think it might be easier to work
>> with than launchd.
>>
>> If you do come up with something, I'd appreciate it if you'd share.
>>
>> Cheers,
>> Clinton Blackmore
>>
>>
>> _________________________________________
>> Casper mailing list
>> Casper at list.jamfsoftware.com
>> http://list.jamfsoftware.com/mailman/listinfo/casper


This email has been scanned by Barracuda Network's Anti-Virus and
Spam Firewall.


Jeffrey A. Strauss
Department of Educational Technology
Systems Administrator
Loyola High School of Los Angeles
1901 Venice Blvd.
Los Angeles, Ca 90006
(213) 381-5121 x265

Please consider the environment before printing this e-mail.

No, what I'm doing now is just adding a folder inside the Office 2008 app folder. I am using MCX to restrict apps, so I'll see how it goes.

Just to make sure there isn't -yet more- confusion, here's the skinny
on application management using MCX (from my Tips doc - p. 32):

d. Applications
Management and control over applications has improved radically since
Tiger. Whereas before, a user could drag an application into their
home directory and alter it to bypass restrictions, and where schools
had to totally disable Dashboard to stop users from running unapproved
Widgets, Leopard MCX has much better control.

1. Applications themselves
There are two different settings for application management, one is
the ability to digitally sign applications to keep them from becoming
altered. While this is a great setting, it does not provide
application restrictions. The setting is missing the ability to set
“don’t allow anything but signed apps to run” or something to that
effect. This renders the signing ineffective as a control mechanism.

What works best for application management is path or folder
restriction. You can set the locations where applications are allowed
to run, and locations that are forbidden. <snip>

(Picture here of the allowed being /Applications and /Library,
disallowed being things like ~/)

The idea here is that the default Applications folder is safe, and
the /Library folder often contains sub-launched apps needed by
mainstream ones. The user does not have permission to mess with either
of these folders. You could further restrict /Library by designating
just the Application Support folder. I found that a few sys admin
apps, such as Sassafras’ K2 tools need to run as a user task from /
Library itself. Note that the user’s homedir is not allowed - so even
if someone downloads an application to their home, they can’t launch
it. You could also deny use of Installer. While the dialog box says
‘Folders’, what it really means is the path. This means that you can
add the path directly to an application as denied. The rules work like
a firewall; so denies always win, and you can allow an app inside a
denied folder - except - if you add the application to the
‘Applications’ pane, it can be launched anywhere, including from
inside the user’s home directory.

johnd
--
John DeTroye Email: johnd at apple.com
Sr. Consulting Engineer Systems Management Specialist
Apple - Education iChat: johnd at mac.com
Systems Management Guide - http://www.apple.com/education/go/sysmgmt/
Tips and Tricks Docs - http://web.me.com/johnd/