• State Suggested Answer
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 2905 views
  • Users 0 members are here
Options
Related

Can we prevent graphics directories on linux system from being renamed or moved by users?

Jaye Mize

We (JAMA Network for the American Medical Association) run XPP on Linux. We have a graphics directory for each journal (eg, CAR_OLF_unscheduled for JAMA Cardiology, DER_OLF_unscheduled for JAMA Dermatology) that graphic artists drop eps files into. At least 20 people have access to these directories and more than half of them use them daily.

Every so often, someone finger fumbles and accidentally moves or renames a directory. Production stops, panic ensues, and managers hyperventilate because the graphics for some or all current jobs are MIA. We have always been able to find the directories and get them back into place within 1/2 hour but we would like to prevent this. 

Today a MacUser accidentally renamed the parent directory and all images were NF but this has happened before on Windows using Samba. 

Does anyone know how to restrict users from moving or renaming these directories while still allowing write access? 

These are the permissions: drwxrwxrwx 2 jmize wheel 94208 Mar 14 19:34 CAR_OLF_unscheduled
Rate translation
×
Suggest better translation
×
Parents
  • 0

    You might try one of these options:

    1. If the problematic graphic artists' login accounts belong to a different "group", then set the permissions on the parent folders of the image folders to drwxrwxr-x (while the permissions on the image folder themselves will still be drwxrwxrwx). This gives write permission on the parent folders only to the "owner" and "group" of those folders.
    2. If everyone's login accounts belong to the same ("wheel") group, then set the permissions on the parent folders of the image folders to drwxr-xr-x (image folders themselves stay as drwxrwxrwx). This gives write permission on the parent folders only to the "owner" of those folders.
    3. If you don't trust yourself (or trust the "owner" of the parent folder) then set the permissions on the parent folders to dr-xr-xr-x. This gives no one (except 'root') write permissions on the parent folders. If you have to go this route, then when you do want to add or rename an image folder you will either have to login as root, or su root, or sudo root or you'll first need to (temporarily) add write permissions back onto the parent folder while you manipulate the image folders within it.

    Depending on how bad is the behavior of your graphic artists, you might need to set the restricted permissions on all of the parent folders of your image directories up to the root (/) folder.

    Jonathan Dagresta
    RWS Group/    XPP Development

  • 0 in reply to Jonathan Dagresta

    Tough love, Jonathan. Grinning

    In the old days (Red Hat EL5), Samba didn't always honor Unix permissions. We never did fully understand how that could be.

    Assuming Jaye and the AMA are on Red Hat 7 (or 8), and SELinux is in use, then security and Samba are very solid. In fact, most of our problems since upgrading to Red Hat EL7 for XPP 9.4+ have been in the opposite direction. For example, Unix symbolic links across file systems all broke. There is a configuration option to allow links to be followed, but in the end, we decided we liked the stronger security, and went through an internal exercise of doing away with those links, updating documentation, and a bit of re-training.
Reply
  • 0 in reply to Jonathan Dagresta

    Tough love, Jonathan. Grinning

    In the old days (Red Hat EL5), Samba didn't always honor Unix permissions. We never did fully understand how that could be.

    Assuming Jaye and the AMA are on Red Hat 7 (or 8), and SELinux is in use, then security and Samba are very solid. In fact, most of our problems since upgrading to Red Hat EL7 for XPP 9.4+ have been in the opposite direction. For example, Unix symbolic links across file systems all broke. There is a configuration option to allow links to be followed, but in the end, we decided we liked the stronger security, and went through an internal exercise of doing away with those links, updating documentation, and a bit of re-training.
Children
No Data