Prevent users from deleting aliases off the desktop

Discussion in 'macOS' started by ninjaconsultant, Jan 21, 2011.

  1. ninjaconsultant macrumors newbie

    Joined:
    Jan 18, 2011
    Location:
    New York City
    #1
    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
     
  2. Cromulent macrumors 603

    Cromulent

    Joined:
    Oct 2, 2006
    Location:
    The Land of Hope and Glory
    #2
    Just do this:

    Code:
    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.
     
  3. ninjaconsultant thread starter macrumors newbie

    Joined:
    Jan 18, 2011
    Location:
    New York City
    #3
    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.
     
  4. Cromulent, Jan 21, 2011
    Last edited: Jan 21, 2011

    Cromulent macrumors 603

    Cromulent

    Joined:
    Oct 2, 2006
    Location:
    The Land of Hope and Glory
    #4
    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:

    Code:
    ls -@
     
  5. ninjaconsultant thread starter macrumors newbie

    Joined:
    Jan 18, 2011
    Location:
    New York City
    #5
    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.

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

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #6
    Code:
    man ls
    Code:
    -@      Display extended attribute keys and sizes in long (-l) output.
    So you need
    Code:
    ls -l@ <FILENAME>
     
  7. Cromulent macrumors 603

    Cromulent

    Joined:
    Oct 2, 2006
    Location:
    The Land of Hope and Glory
    #7
    Sorry, ignore me I'm just grumpy.

    My bad. I meant:

    Code:
    ls -le
    Edit:

    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.
     
  8. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #8
    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:
    Code:
    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.
     
  9. ninjaconsultant thread starter macrumors newbie

    Joined:
    Jan 18, 2011
    Location:
    New York City
    #9
    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.
     
  10. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #10
    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).
     
  11. Hal Itosis macrumors 6502a

    Hal Itosis

    Joined:
    Feb 20, 2010
    #11
    There is no group called root. (gid 0 = 'wheel')


    True.


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

    chmod +a "group:everyone deny delete" /path/to/the/alias
     
  12. ninjaconsultant thread starter macrumors newbie

    Joined:
    Jan 18, 2011
    Location:
    New York City
    #12
    Sorry for the late reply!

    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!
     
  13. Detrius macrumors 68000

    Joined:
    Sep 10, 2008
    Location:
    Asheville, NC
    #13
    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.
     
  14. larkost macrumors 6502a

    Joined:
    Oct 13, 2007
    #14
    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.
     
  15. ninjaconsultant thread starter macrumors newbie

    Joined:
    Jan 18, 2011
    Location:
    New York City
    #15
    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.

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

Share This Page