Prevent users from deleting aliases off the desktop

[ninjaconsultant]

I administer a few classrooms running Mac OS X 10.5.8.

I've created an alias on the desktop of the student's machines that links to a shared folder on a server (well, not a real server, but a regular machine sharing files). I don't want the users (students) to be able to delete this alias. I've changed the owner to administrator, I've locked the icon, but it doesn't seem to matter. Users can still drag locked icons into the Trash (and delete them by holding shift...).

I tried setting the owner to root, but I've found this doesn't quite work, since I don't have root enabled on the machines by default. I can't seem to chown the file without logging in as root, which is a pain. Even after I successfully used the following:

chown root SharedFolderAliasName

I was still able to delete the alias logged in as Student.

I've been googling for a solution but haven't found any Mac options.

Maybe I should/could write an Applescript to check for the icon and create it if it doesn't exist (the username and password are stored in a keychain) but I'm not quite sure how to do that.

If anyone knows of some good housekeeping scripts to delete everything from the desktop every night (except my desired alias), please post a link.

P.S.
I'm using Apple Remote Desktop 3.4

 

[Cromulent]

I've created an alias on the desktop of the student's machines that links to a shared folder on a server (well, not a real server, but a regular machine sharing files). I don't want the users (students) to be able to delete this alias. I've changed the owner to administrator, I've locked the icon, but it doesn't seem to matter. Users can still drag locked icons into the Trash (and delete them by holding shift...).

I tried setting the owner to root, but I've found this doesn't quite work, since I don't have root enabled on the machines by default. I can't seem to chown the file without logging in as root, which is a pain. Even after I successfully used the following:

chown root SharedFolderAliasName

I was still able to delete the alias logged in as Student.

I've been googling for a solution but haven't found any Mac options.

Maybe I should/could write an Applescript to check for the icon and create it if it doesn't exist (the username and password are stored in a keychain) but I'm not quite sure how to do that.

If anyone knows of some good housekeeping scripts to delete everything from the desktop every night (except my desired alias), please post a link.

P.S.
I'm using Apple Remote Desktop 3.4

Just do this:

sudo chown root:root <filename>
sudo chmod 644 <filename>

Job done. You don't need to have root enabled you just need to use sudo.

 

[ninjaconsultant]

Just do this:

sudo chown root:root <filename>
sudo chmod 644 <filename>

Job done. You don't need to have root enabled you just need to use sudo.

Well, sudo chown root:root asks for a password, then tells me I'm not in the sudo file. (I was logged in as student...)

Logged in as an administrator, I was eventually able to change permissions to this:

-r--r--r--@ 1 root staff 0 Jan 19 11:19 <filename>

But it doesn't matter - I can still delete the alias while logged in as student.

 

[Cromulent]

Well, sudo chown root:root asks for a password, then tells me I'm not in the sudo file. (I was logged in as student...)

Logged in as an administrator, I was eventually able to change permissions to this:

-r--r--r--@ 1 root staff 0 Jan 19 11:19 <filename>

But it doesn't matter - I can still delete the alias while logged in as student.

Well, yes. Sorry I assumed you knew that sudo required administrator access. Interesting that you can be in charge of a network and not know about sudo...

Anyway back on topic, what user group are students a member of? The fact that there is an @ after the permissions means that file has extended permissions.

Type the following to see what they are:

ls -@

 

[ninjaconsultant]

Well, yes. Sorry I assumed you knew that sudo required administrator access. Interesting that you can be in charge of a network and not know about sudo...

It could be that I'm new at this Unix thing, and only in charge of a small group under the umbrella of a much larger university.

Anyway back on topic, what user group are students a member of? The fact that there is an @ after the permissions means that file has extended permissions.

Type the following to see what they are:

ls -@

That command seems to list all of the files on the Desktop.

 

[balamw]

That command seems to list all of the files on the Desktop.

man ls

-@      Display extended attribute keys and sizes in long (-l) output.

So you need

ls -l@ <FILENAME>

 

[Cromulent]

It could be that I'm new at this Unix thing, and only in charge of a small group under the umbrella of a much larger university.

Sorry, ignore me I'm just grumpy.

That command seems to list all of the files on the Desktop.

My bad. I meant:

ls -le

Edit:

man ls

-@      Display extended attribute keys and sizes in long (-l) output.

So you need

ls -l@ <FILENAME>

True, although pointless. Extended attributes are the wrong thing to look for in this case. That was my mistake. See above for what you really want.

 

[chown33]

On Unix systems, it's only necessary to have write permissions on a directory in order to delete files in that directory. Think about why this is so: deleting a file modifies the list of files that is the directory.

So unless you get tricky or use ACLs (which can be tricky), you can't prevent deletion unless you change the permissions of the directory holding the file. Yet doing that would also prevent users from deleting their own files (unless you resort to further trickery, like the sticky bit).


I recommend setting the lock flag. To do this with a shell command:

chflags uchg /path/to/file

If the file is owned by root, then only root will be permitted to change the flags. After setting this flag, Finder will prevent moving, renaming, deleting, or writing to the file. You should probably confirm this by testing each of those, because it's been a long time since I did this and I may have forgotten something.

Anyway, chflags is a lot easier than ACLs.

Be sure to read the man page for chflags, and experiment on a file-system you don't care about.


Whatever you do, DO NOT set the schg flag. If you do, it will be nearly impossible to clear the flag, or modify the file, unless you boot into single-user mode and clear the flag using commands. You may think that sounds like exactly what you want, but it's a lot harder to correct if you make a mistake. Using chown and chflags is much more easily recoverable, and should have the same consequences in this situation.

 

[ninjaconsultant]

I recommend setting the lock flag. To do this with a shell command:

chflags uchg /path/to/file

If the file is owned by root, then only root will be permitted to change the flags. After setting this flag, Finder will prevent moving, renaming, deleting, or writing to the file. You should probably confirm this by testing each of those, because it's been a long time since I did this and I may have forgotten something.

Anyway, chflags is a lot easier than ACLs.

Be sure to read the man page for chflags, and experiment on a file-system you don't care about.

Wow, thank you!

At first I thought this did exactly what I was hoping for. But then I realized that it just locks the file the same way you can lock it from the Finder if you check off "Locked" after you get info.
Users can still delete the shortcut from the desktop if they click "Continue" when prompted:

"Item <itemname> is locked. Do you still want to move it to the Trash?"

Users can then empty the trash by holding option - which the system reminds you of when you try to empty the Trash with locked items in it.

 

[kainjow]

Are the student accounts setup as Standard? I have a Standard account where I made a folder on its Desktop while logged in to my Admin account via sudo so owner/group was root:staff. When I logged into the Standard account I am asked for the password when I try to trash it. I do have root enabled, maybe you should enable that (although you'd think there'd be a better way).

 

[Hal Itosis]

Just do this:

sudo chown root[COLOR="Magenta"]:root[/COLOR] <filename>
sudo chmod 644 <filename>

There is no group called root. (gid 0 = 'wheel')

But then I realized that [chflags uchg] just locks the file the same way you can lock it from the Finder if you check off "Locked" after you get info.

True.

I administer a few classrooms running Mac OS X 10.5.8.

I've created an alias on the desktop of the student's machines that links to a shared folder on a server (well, not a real server, but a regular machine sharing files). I don't want the users (students) to be able to delete this alias.

ACLs can take time to learn, but they're not that scary...

chmod +a "group:everyone deny delete" /path/to/the/alias

 

[ninjaconsultant]

Sorry for the late reply!

ACLs can take time to learn, but they're not that scary...

chmod +a "group:everyone deny delete" /path/to/the/alias

This worked! I had to throw a "sudo" in front, and it asked for a password, but now I'm prompted for a login if I try to delete the alias. That is awesome! Thanks!

I was hoping to implement this fix using Apple Remote Desktop. I can send Unix commands with it just fine, but ARD doesn't seem to handle the password prompt and usually returns an error.

I've done a very lame workaround with Applescript in the past, scripting the machines to open terminal, sending the command, and then typing the password... but making Applescript type things sometimes returns errors, especially when it comes to special characters (like a backslash or exclamation mark)... Anyway, I suppose this is another issue entirely.

Thanks for your help everyone! I learned a lot!

 

[Detrius]

You people all missed the insanely simple proper Unix solution to this. Deleting a file does not amount to changing the file, and technically, the permissions on the file should be irrelevant. The way this is done in Unix is you change the permissions on the folder, as deleting a file is a modification to the folder. Therefore, it would be something like this:

chown root:wheel Desktop
chmod 755 Desktop


Granted, it blocks adding/deleting anything to/from the Desktop, so if ACLs denying any changes to the file do the trick, then that's a better solution, but I'm surprised this thread got all the way to ACLs without someone mentioning the above. Tisk tisk.

 

[larkost]

The best way of handling this situation is not to worry about them deleting the file, but rather to setup a system that will restore everything that should be there on login (loginhook, or launchd item). That way you don't even have to worry about students adding things to the login. One login/logout (or reboot if that so pleases you), and everything is back to how you expect it. I have used rsync for simple setups, and more complex scripting for more complex ones.

 

[ninjaconsultant]

The way this is done in Unix is you change the permissions on the folder, as deleting a file is a modification to the folder.

Changing the permissions so the students can't save anything to the desktop seems like overkill for our particular lab environment... I don't mind the users using the desktop for temporary storage.

The best way of handling this situation is not to worry about them deleting the file, but rather to setup a system that will restore everything that should be there on login (loginhook, or launchd item). That way you don't even have to worry about students adding things to the login. One login/logout (or reboot if that so pleases you), and everything is back to how you expect it. I have used rsync for simple setups, and more complex scripting for more complex ones.

Rsync seems like an interesting option... I'd never thought of syncing the desktop as a directory.