Tux

...making Linux just a little more fun!

Restrict the number of files a user can delete at a time

Suramya Tomar [security at suramya.com]


Wed, 06 Feb 2008 20:37:58 +0530

Hey Everyone, A friend of mine asked the following question and as far as I know its not possible but if I am wrong please correct me.

Basically what he wants to do is share files with windows systems over samba (with write/delete access) and restrict the number of files a user can delete at a time. So if a user (suramya) wanted to delete 2 files the system would let him delete it, but if he tried to delete 50 files it would stop it.

What do you think? Is it possible? What I told him was that either you give a user delete access or not but you can't limit by the number of files.

The easiest way I have found to remove delete access is to remove the write access to the parent directory containing the files. But the downside of this is that the users can't add new files. In this case since the users are programmers they have to have the ability to add new files to the directory.

So what are his options?

- Suramya

-- 
Name : Suramya Tomar
Homepage URL: http://www.suramya.com
************************************************************


Top    Back


Neil Youngman [Neil.Youngman at youngman.org.uk]


Wed, 6 Feb 2008 15:25:06 +0000

On Wednesday 06 February 2008 15:07, Suramya Tomar wrote:

> Hey Everyone,
>   A friend of mine asked the following question and as far as I know its
> not possible but if I am wrong please correct me.
>
>   Basically what he wants to do is share files with windows systems over
> samba (with write/delete access) and restrict the number of files a user
> can delete at a time. So if a user (suramya) wanted to delete 2 files
> the system would let him delete it, but if he tried to delete 50 files
> it would stop it.
>
>   What do you think? Is it possible? What I told him was that either you
> give a user delete access or not but you can't limit by the number of files.

I'm not enough of an expert on SAMBA to know if it is easy to hook into SAMBA and implement custom functions hooked to deletion. I think it's unlikely to be easy. There might be ways to do it based on fuse http://fuse.sourceforge.net/, but again I'm no expert.

> So what are his options?

Possibly FUSE, but a simpler approach would be master and shadow directories. Let them do what they like in the shadow directory, but there is a process or cronjob that either propagates changes to the master directory or reverts any changes that aren't permitted.

Neil


Top    Back


Ben Okopnik [ben at linuxgazette.net]


Wed, 6 Feb 2008 10:46:35 -0500

On Wed, Feb 06, 2008 at 08:37:58PM +0530, Suramya Tomar wrote:

> Hey Everyone,
>   A friend of mine asked the following question and as far as I know its 
> not possible but if I am wrong please correct me.
> 
>   Basically what he wants to do is share files with windows systems over 
> samba (with write/delete access) and restrict the number of files a user 
> can delete at a time. So if a user (suramya) wanted to delete 2 files 
> the system would let him delete it, but if he tried to delete 50 files 
> it would stop it.
> 
>   What do you think? Is it possible? What I told him was that either you 
> give a user delete access or not but you can't limit by the number of files.
> 
> The easiest way I have found to remove delete access is to remove the 
> write access to the parent directory containing the files. But the 
> downside of this is that the users can't add new files. In this case 
> since the users are programmers they have to have the ability to add new 
> files to the directory.
> 
> So what are his options?

The traditional way to handle this kind of permissions problem is via an SUID program: you deny delete perms to the user, allow them for a "special" user that you create, and set up the program to be SUID that special user.

These are also the scenarios in which you need to be extremely paranoid about privilege escalation - the only thing standing between your users and full rights on the remote system is a single program bug.

-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *


Top    Back


Suramya Tomar [security at suramya.com]


Tue, 12 Feb 2008 18:56:31 +0530

Hey,

> The traditional way to handle this kind of permissions problem is via an
> SUID program: you deny delete perms to the user, allow them for a
> "special" user that you create, and set up the program to be SUID
> that special user.
> 
> These are also the scenarios in which you need to be extremely
> paranoid about privilege escalation - the only thing standing between
> your users and full rights on the remote system is a single program bug.

Thanks for the info. I don't think I want to go that route as its too complicated to setup and I don't want to be responsible for maintaining it. :)

- Suramya

-- 
Name : Suramya Tomar
Homepage URL: http://www.suramya.com
************************************************************


Top    Back


Karl-Heinz Herrmann [kh1 at khherrmann.de]


Wed, 6 Feb 2008 23:56:01 +0100

On Wed, 06 Feb 2008 20:37:58 +0530 Suramya Tomar <security@suramya.com> wrote:

>   Basically what he wants to do is share files with windows systems
> over samba (with write/delete access) and restrict the number of
> files a user can delete at a time.

Hm.... no idea with out of the box tools.

> The easiest way I have found to remove delete access is to remove the 
> write access to the parent directory containing the files. But the 
> downside of this is that the users can't add new files. In this case 
> since the users are programmers they have to have the ability to add
> new files to the directory.

Maybe something else is enough -- at least with *nix filesystems (etx2/3,xfs,..) you can set a sticky bit on directories. These cause that everybody can delete his OWN files but not other files but can creat (i.e. write) as he wants.

If a user wants to destroy all information this still allows him to overwrite all files with zeros -- but an accidential delete will ownly destroy the files of the user -- which might be educational at least.

Setting a dir this way is done by:

chmod 4755 dir

samba will pass this on if users are conneting with different user names.

K.-H.


Top    Back


Suramya Tomar [security at suramya.com]


Tue, 12 Feb 2008 23:53:59 +0530

Hey Everyone,

> Hm.... no idea with out of the box tools. 

I looked into this some more and have figured out a way that somewhat does what my friend wants to using rsync. Basically we maintain two copies of the data, one which the user(s) write to using samba and the second which is our master copy. Once every few hours we sync the two directories and if the number of files to be deleted exceed a given value we send out an email and sync the files without deleting anything. If the value is not exceeded we go ahead and delete the files in the master copy also.

Below is the script I wrote that does the above:

--- Start SafeSync.sh ---
 
#!/bin/bash
MAX_DELETE=3
SOURCE_DIR="Projects/"
TARGET_DIR="Projects_Master"
 
PARAMETERS=" -avrz --log-file=/tmp/rlog 
--backup-dir=/home/suramya/Preserve -b $SOURCE_DIR $TARGET_DIR "
 
rsync -n --max-delete=$MAX_DELETE --delete $PARAMETERS
e=$?
if test $e = 25; then
    touch /tmp/deletedList
    touch /tmp/TodeleteList	
 
    rsync -n --delete $PARAMETERS |grep delet > /tmp/TodeleteList
 
    printf "The sync program tried to delete more than the allowed no of 
files($MAX_DELETE). \n\nThe following files remain in the delete queue: 
\n\n`cat /tmp/TodeleteList`. \n\nPlease delete the files manually from 
'$TARGET_DIR' to avoid this warning." > /tmp/message
 
    ./sendEmail/sendEmail  -f suramya@suramya.com -t suramya@suramya.com 
-u "Test"  < /tmp/message
 
# Now we sync the remaining files so that we have a synced directory
 
    rsync $PARAMETERS
 
    rm /tmp/TodeleteList
    rm /tmp/message
else
 
# We didn't trip the max delete flag so we go ahead and sync the files
    rsync --max-delete=$MAX_DELETE --delete $PARAMETERS
 
fi
exit $e

In this script, the user will have to manually delete the files in the Master directory if the number of deleted files exceed the MAX_DELETE value.

I know that the script is not very efficient. I have to run rsync twice, first to check if the sync would fail, then we do the actual sync or get the list of files that would have been deleted. Is there a way I can do this without having to run the command twice?

Is there anything else that you think I should change in this to make it better?

Looking forward to your feedback.

Thanks, Suramya

PS: I use the ./sendEmail/sendEmail to send the email as I found it easier to configure for SMTP servers than mail. You can use either one.

-- 
Name : Suramya Tomar
Homepage URL: http://www.suramya.com
************************************************************


Top    Back


Ben Okopnik [ben at linuxgazette.net]


Tue, 12 Feb 2008 17:34:04 -0500

On Tue, Feb 12, 2008 at 11:53:59PM +0530, Suramya Tomar wrote:

> 
> In this script, the user will have to manually delete the files in the 
> Master directory if the number of deleted files exceed the MAX_DELETE value.
> 
> I know that the script is not very efficient. I have to run rsync twice, 
> first to check if the sync would fail, then we do the actual sync or get 
> the list of files that would have been deleted. Is there a way I can do 
> this without having to run the command twice?

Seems to me like running 'rsync' once and then interpreting the results would make sense.

#!/bin/sh
 
MAX=3
/usr/bin/rsync --max-delete=$MAX --delete [ ...whatever parameters... ]
if [ "$?" -eq 25 ]
then
	printf "$MAX files deleted, the rest ignored. Next time, we'll poison your puppies.\n"
	# Send mail, whatever...
	exit 1
fi
printf "You got away with deleting my files _this time,_ but I'd watch it if I were you.\n"
-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *


Top    Back


Suramya Tomar [security at suramya.com]


Wed, 13 Feb 2008 22:57:09 +0530

Hey Ben,

> Seems to me like running 'rsync' once and then interpreting the results
> would make sense.

True, but I wanted to avoid deleting files if I could. I know we could restore them from the backup directory but thats just extra work for the person maintaining the system.

Plus having a list of files that were supposed to be deleted when more than the allowed number was being deleted would let the admin figure out if the deletion is to be allowed or not.

- Suramya

-- 
Name : Suramya Tomar
Homepage URL: http://www.suramya.com
************************************************************


Top    Back


Ben Okopnik [ben at linuxgazette.net]


Wed, 13 Feb 2008 13:48:44 -0500

On Wed, Feb 13, 2008 at 10:57:09PM +0530, Suramya Tomar wrote:

> Hey Ben,
> 
> > Seems to me like running 'rsync' once and then interpreting the results
> > would make sense.
> 
> True, but I wanted to avoid deleting files if I could. 
> 
> I know we could 
> restore them from the backup directory but thats just extra work for the 
> person maintaining the system.

Ah - I'd misunderstood. I thought you wanted to delete no more than $MAX files, which is what that 'rsync' switch does. From the 'rsync' man page:

 
 --max-delete=NUM        don’t delete more than NUM files
 
[...]
 
EXIT VALUES
 
[...]
 
       25     The --max-delete limit stopped deletions

I.e., there shouldn't be anything for you to restore: 'rsync' will actually stop deleting at that number of files.

If you don't want to delete anything at all once the user exceeds a given number of files, then doing it the way you are is reasonable - or maybe doing a comparison using 'diff -r /dir/source /dir/target' would give you what you're looking for.

> Plus having a list of files that were supposed to be deleted when more 
> than the allowed number was being deleted would let the admin figure out 
> if the deletion is to be allowed or not.

Either of the above approaches would give you that.

-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *


Top    Back