Script to change permissions for a group of users 1

[dizwald]

Issue: I'm working on a system where relatively naive users need to set up 'compliant' directory structures to a set format and re-set group ownership (chgrp) of lower level directories so they have write permissions but the directory they need to create in doesn't have write access for their group.
To get around this the script was going to have the SGID set but I've just found out that using SGID on the program is fraught with security issues.

Question: Is there a way (apart from using SGID) to allow users from different group access to a script to create directories in a directory where they do not have write permissions?

 

[LKBrwnDBA]

Quote:
Question: Is there a way (apart from using SGID) to allow users from different group access to a script to create directories in a directory where they do not have write permissions?

Wouldn't that defeat the purpose of having WRITE permissions?


----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[dizwald]

The point is that the 'compliant' directory structures are quite complicated, and to be compliant, shouldn't have any extra directories cluttering the hierarchy.
Just to make sure that the the right directory structure is created is a feat in itself with our users ;-)
So to prevent directory proliferation, which did happen on VMS (with the same users) we wanted to be able to allow users to create the directory structure (one per new project) at will, using a script which allowes them to pick options from a list, Only at the very bottom level (3 levels down from starting directory), are they allowed to create files/directories.

 

[mrn]

Take a look at sudo

Mike

"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant.

 

[dizwald]

?

 

[stefanwagner]

Perhaps you may explain the users what they are allowed to do and what they should avoid - and generate a script which monitores their directories, so you may correct them early?

A printed explanation with a little bit of graphics could simplify the job of explanation and help the users to remember the rules.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[Mike042]

Hi dizwald,

Perhaps not a very elegant solution but how about this for an idea:

Write a script that the users can run (owned by root and rwxr-xr-x) that prompts them for some information (eg new Project name for directory structure) and also grabs other information (eg username of user running the script, his/her GID, etc) and writes this data to a time-stamped file (in say /var/tmp). (NB: time-stamped so that its name is unique to this user and project)

Write a second script that runs as root (rwxr--r--) from crontab every 30 mins, Monday to Friday, 07:00 to 19:00 (or however often is deemed necessary, during the working day) that tests for the existence of the time-stamped files and then creates the correct directory structure (if it doesn't already exist - in case of duplication) with all the right access permissions and ownership and finally (optionally) e-mails the user to say it is done. Don't forget to remove or rename the time-stamped file after it is processed.

I hope that helps, if only to generate further thoughts.

Mike

 

[dizwald]

Hi Mike.
That certainly has helped. Thanks for switching the thought processes around.

 

[RodKnowlton]

With sudo, you can write your script as originally planned, save it as rwx------ root, and grant users specific permission to run the script as root.

Benefits:

- All instances can be logged automatically by sudo
- "Curious" users (one of the most dangerous kinds) can't see specifically what the script does
- The actual user information can be obtained from the SUDO_* environmental variables
- No root cron job just begging some joker to queue up 1,000,000 directory creation jobs

I always assume, no matter how naive my users are, that some day there will be one that knows even more than I do, and isn't as nice. So if I can think of a way to abuse a process or break something, I have to assume that I'm not the only one that would think of it, and find a way to mitigate or eliminate the exposure.

Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L