Permissions, permissions, permissions...

SwampThing

The bane of my life!

Ok, here's my problem.

I have a directory full of scripts that various users use to do different things. Some are run in crons, some manually and some both ways. And they're all run by a number of different users. Let's say all users are part of the 'users' group. These users must not have write access to the script files.

A good number of these scripts generate output files in the same directory as the script, and this can't change.

I have another group of users, say memebers of a group called dba, which I want to be able to modify the scripts.

So, how do I do it?

In case I haven't explained very well, an example. Two users, joe(users) and dbman(dba). A directory full of scripts, called scrdir. A script called sendfile.
When run, sendfile generates an output file - snd.out.
I want joe to be able to run sendfile and have permissions on the scrdir directory to create the snd.out file but not to modify the sendfile script. User dbman however has permission to modify and run sendfile.

Any takers?

nadir

chown -R root:dba srcdir
chmod 777 srcdir
chmod 775 srcdir/*

a setup like this would be better though

chown -R dbauser:users srcdir
chmod 770 srcdir
chmod 750 srcdir/*

and run stuff as dbauser

SwampThing

Thanks, but your first suggestion it doesn't work.

A file in srcdir - with rwxrwxr-x , root:dba. I vi it as a normal user, and I can over-write it. What's more, the file now is owned by this user and the group changes to users. Permissions stay at rwxrwxr-x.

I'll try your second suggestion now.

SwampThing

SwampThing wrote:

I'll try your second suggestion now.

Same thing - no joy.

What about the SUID and SGID - are these any good to me here?

Khannie

Can't see an obvious solution tbh, though I'm no guru.

How about this for a workaround......

have your users group scripts output to /tmp
then have another script running from a dba user that checks the /tmp directory for your file type, then copies it to your specific directory. One check every, say, 5 seconds? Or whatever. Easy to write an infinite loop script to do this. Sloppy, but effective.

Dero

Hmm. Set the permissions of srcdir to 1777 (same as /tmp). this will allow anyone to create files, but only delete their own files. Then chown the scripts so that they are owned by dbuser:dba and give read+execute permission to everyone (755).

chmod 1777 srcdir
chown dbauser:dba srcdir/sendfile
chmod 755 srcdir/sendfile

Not sure if I'm missing anything here. You could, assuming dbauser is in users, chown the script to dbauser:users. Then it wouldn't need to be world readable and executable.

cormy

Swampthing - what OS is all of this running on?

nadir

SwampThing wrote:

Thanks, but your first suggestion it doesn't work.

A file in srcdir - with rwxrwxr-x , root:dba. I vi it as a normal user, and I can over-write it. What's more, the file now is owned by this user and the group changes to users. Permissions stay at rwxrwxr-x.

I'll try your second suggestion now.

shouldnt happen, only dba group and root should have write access to those files. maybe your groups are misonfigured?

AndrewMc

SwampThing wrote:

Thanks, but your first suggestion it doesn't work.

A file in srcdir - with rwxrwxr-x , root:dba. I vi it as a normal user, and I can over-write it. What's more, the file now is owned by this user and the group changes to users. Permissions stay at rwxrwxr-x.

I suspect what happened is that by saving the file vi essentially deleted the original file and created a new one. According to the suggestion you followed, you would have the permissions 0777 on the directory, which means all users have full control over the directory. Although you don't own the file itself, you have permission to remove the directory's link to the file. Hey presto, file gone. Then you make your new one, which has your username on it.

Using the "sticky" bit on the directory (1777) basically means that users have full control over the directory, except in the case where individual file permissions say otherwise. Specifically, from the chmod(1) man page:

When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable.

SwampThing

Dero, I'll try your suggestion now.

cormy - I'm using RedHat ES 3 - this is a production server - if I was arseing around at home I wouldn't give two hoots about it.

To add a little to the mix.

The reason I mention the SUID / SGID bits it this. I thought if I set the SUID on a script that is dbauser:dba, and user could execute the script with that users permissions. That way, the script would have permission to create the output files. However, if the user just vi's the scripts, or tries to create a file any other way, they wouldn't be permitted.

I know it's a bit of a 'why would you do it this way'. I'm migrating a production Tru64 Alpha to linux and this is my opportunity to tighten up security a bit - too many wanna-be sys admins here.

Thanks again for the suggestions - I'll update a little later.

SwampThing

Dero wrote:

Hmm. Set the permissions of srcdir to 1777 (same as /tmp). this will allow anyone to create files, but only delete their own files. Then chown the scripts so that they are owned by dbuser:dba and give read+execute permission to everyone (755).

chmod 1777 srcdir
chown dbauser:dba srcdir/sendfile
chmod 755 srcdir/sendfile

Not sure if I'm missing anything here. You could, assuming dbauser is in users, chown the script to dbauser:users. Then it wouldn't need to be world readable and executable.

Dero, those permissions allow any user to create a file in scrdir.
Thanks anyway.

Dero

Yes, that's true. But like I said, just chown srcdir to dbauser:users, and chmod to 1774 or 1770 or whatever you like. Then others outside of the users group will not be able to write (or even enter the dir if you don't want). The best approach would probably be to set up a group containing just the users you want to access the dir and make sure the scripts are owned by whoever should have write access to them and be executable and readable by group members and nothing to others (750). How many users are we talking about here? How many need write access to the scripts? I presume they all need write access to the dir for script output?

SwampThing

Here's the kicker.

Any user on the system, irrespective of which group they belong to, can run the scripts in that directory. The scripts in turn generate output files in the same directory.

If a joebloggs:users runs the script, the output file still needs to be generated. But I don't want joebloggs:users to modify scripts in the directory or create files at will.

That's why I was asking about the SUID bit - I thought I could lock down the directory - non-dba users couldn't modify/create files - but by executing a script with the right permissions, the script would be able to create the output files.

The script would need to be owned dbauser:dba; have the SUID bit set, which lets any user execute it with the owners (dbuser) priveledges.

The script which allows users to 'su' up to root works a bit like this I think.

I know it's akward, but once in place, I'd have a very secure directory of scripts that I know can't be modified and/or added to.

I'm just a bit out of my depth with the setup.

Thanks for your time on this lads.

SwampThing

Nobody beaten with the inspiration stick over that past few days?

I'm still tearing my hair out on this one. Anyone? Thanks...

AndrewMc

SwampThing wrote:

Nobody beaten with the inspiration stick over that past few days?

I'm still tearing my hair out on this one. Anyone? Thanks...

Okay, hopefully not forgetting anything:

Create a new user, say "dbascript" and add them to a new group called "dbascript"

chown root.dbascript srcdir
chmod 2775 srcdir
chown dbascript.dba srcdir/{script1,script2,...}
chmod 4575 srcdir/{script1,script2,...}

So... scripts are run setuid as user dbascript, and only somebody in group dbascript (which is dbascript himself) can write the output files to the directory. To be extra-sure, the directory is setgid to force the group of any new files to be dbascript, too. Secondly, the scripts are writable by group dba, but nobody else. If somebody can break a script causing it to overwrite a script you may have a problem - ideally, try to fix the scripts!

Alternatively, if the output files are created with the same name every time by immediately overwriting the previous one (instead of delete-and-create), you may not need to give anyone write-access to the directory. Simply "touch" the output files and make them root-owned and world-writable instead (and avoid almost all this mucking around with user/group permissions). That way the script can overwrite with new output, but nobody can modify the directory any other way (not even delete the output files).

SwampThing

Thanks for that Andrew. I have been able to set ip up like that - i.e. create the output files first and chmod/chown them so any user can overwrite them. I think that's what I'll end up doing.

Thanks again.