How to disallow a user removing a directory but allow removing files within it?

Problem is this:
Many of our ftp users delete certain necessary directories in their home directories. To
avoid the problems related to this I made those directories owned by root. All the files
within that directory are still owned by the user and writable by him. The problem is he
can't remove the files. The user can still write to the files, but he can't delete them.
Is there a way to give the user delete "permission"? (They only need read and delete
permission.)

Kai

Kai Schaetzl <ng@conactive.com> wrote
news:VA.00003075.01f971ac@conactive.com:

> Problem is this:
> Many of our ftp users delete certain necessary directories in their
> home directories. To avoid the problems related to this I made those
> directories owned by root. All the files within that directory are
> still owned by the user and writable by him. The problem is he can't
> remove the files. The user can still write to the files, but he can't
> delete them. Is there a way to give the user delete "permission"?
> (They only need read and delete permission.)

There is no 'delete' permissions.

A file or a directory can be delete if you can modify (write access
enable) the directory that content it.

So to 'protect' a directory you should disable writing in its parent
directory.

In your case you have disable write access (because of the default group
permissions flag) to your concerned directory and so user can't remove
their file.

Set the parent directory of you concerned directory to the root owner or
remove its write permission flag.

But your user won't be able to create file or directory in this parent
directory.

There is other way to solve your problem (sticky bit, user/group/other
permission, ...), but you need to give us more information :

- chrooting user access in the home directory ?
- other way to access the home directory ?
- need to write in the parent directory ?
....


Regards

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.security Kai Schaetzl <ng@conactive.com> suggested:
> Problem is this:
> Many of our ftp users delete certain necessary directories in their home directories. To
> avoid the problems related to this I made those directories owned by root. All the files
> within that directory are still owned by the user and writable by him. The problem is he
> can't remove the files. The user can still write to the files, but he can't delete them.
> Is there a way to give the user delete "permission"? (They only need read and delete
> permission.)

You could try setting the immutable bit on the directory, if the
FS in question supports those file attributes.

man chattr
man lsattr

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)

Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of spam.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAjO28AkPEju3Se5QRAiA8AJwMfeGAMdZacHSgm6X1gF pZ1/5SIQCg2b6r
dFZH3wGpu59+G5AASYbbpfc=
=DYwg
-----END PGP SIGNATURE-----

Antoine EMERIT schrieb am 25 Apr 2004 19:47:23 GMT:

> Is there a way to give the user delete "permission"?
> > (They only need read and delete permission.)
>
> There is no 'delete' permissions.

That's why I used the quotes around the first appearance of "permission"
;-)

> But your user won't be able to create file or directory in this parent
> directory.

That's exactly the problem. Users should be able to read, write and execute
within all of their home directory except for a few directories which
shouldn't get deleted. Typical examples are the cgi-bin or the stats. Users
often carelessly remove them or tell their upload program to do it because
"I uploaded our relaunched website and thought I just remove everything
before doing so". This is nothing critical and not security relevant as the
other answer by "Huge" seems to want to suggest, but it's annoying and
creates some extra work even if you automate recreating that stuff. It
would be easier to just disallow removing these directories.

>
> There is other way to solve your problem (sticky bit, user/group/other
> permission, ...), but you need to give us more information :

I contemplated sticky bit, but I don't see how it would help here.

>
> - chrooting user access in the home directory ?
> - other way to access the home directory ?
> - need to write in the parent directory ?

It's a chrooted standard home directory, user has access only via FTP,
server is vsftpd, as said above user should have all usual permissions
within his homedir just not be able to remove a certain few directories
(but be able to remove files within that dir!). So I chowned those
directories to root, the group is the user's group and it is allowed to
read and traverse the directory.

So far I haven't found a method to achieve the goal with Linux file
permissions. I suppose the only way is to use an FTP server which has this
functionality built-in. I checked the vsftpd documentation and they have a
function which "hides" directories from the user, but it also hides all
stuff beneath, which is not desired.


Kai
--

Conactive Internet Services, Berlin, Germany

Huge schrieb am 25 Apr 2004 17:23:07 GMT:

> >Many of our ftp users delete certain necessary directories in their home directories.
>
> I suggest that you shrug and go back to whatever you were doing.
>

I suggest that you shrug and contemplate if cryptic answers do any good.

Kai
--

Conactive Internet Services, Berlin, Germany

Michael Heiming schrieb am Mon, 26 Apr 2004 11:08:45 -0000:

> You could try setting the immutable bit on the directory, if the
> FS in question supports those file attributes.
>
> man chattr
> man lsattr
>

Thanks for the suggestion, I wasn't aware of that. It seems that either
the "i" or "u" options could help. FS is ext3, so I hope it supports the
same attributes as ext2.

Kai
--

Conactive Internet Services, Berlin, Germany

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.security Kai Schaetzl <ng@conactive.com> suggested:
> Michael Heiming schrieb am Mon, 26 Apr 2004 11:08:45 -0000:

> > You could try setting the immutable bit on the directory, if the
> > FS in question supports those file attributes.
> >
> > man chattr
> > man lsattr
> >

> Thanks for the suggestion, I wasn't aware of that. It seems that either
> the "i" or "u" options could help. FS is ext3, so I hope it supports the
> same attributes as ext2.

Yep, works on ext2/3 the same way.

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)

Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of spam.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAjQm3AkPEju3Se5QRAoPeAJ4sEYsrH5Sdn5fRVS00Em pZpotcwwCgvqK5
28n7Ca95H5TxkH0P4eNq74U=
=SitL
-----END PGP SIGNATURE-----

Kai Schaetzl schrieb am Mon, 26 Apr 2004 14:04:23 +0200:

> Thanks for the suggestion, I wasn't aware of that. It seems that either
> the "i" or "u" options could help. FS is ext3, so I hope it supports the
> same attributes as ext2.
>

Unfortunately, "chattr +i dir" doesn't help. It makes the whole path immutable, so any files below the
directory are also protected and cannot get removed or created or written. It's even worse than chowning the
dir to root. :-(

But, I kept playing around with it and I can make use of it with a trick. When I touch a file *in* a
directory and make it immutable it will effectively stop any attempt to remove that directory. It will also
protect any subdirs and files within it against the usual remove methods of FTP clients, so it protects the
complete directory and contents against accidental deletion, but still allows "picky" deletion of single
files or directories.
So what I do now is touch ".nodelete" and chown it root (I guess the latter is not necessary, anyway) in all
directories I want to protect. That makes it also invisible for most FTP clients and unremovable.
Maybe that explanation helps others as well.
Thanks for the tip!

Kai
--

Conactive Internet Services, Berlin, Germany

Michael Heiming schrieb am Mon, 26 Apr 2004 13:08:08 -0000:

> > Thanks for the suggestion, I wasn't aware of that. It seems that either
> > the "i" or "u" options could help. FS is ext3, so I hope it supports the
> > same attributes as ext2.
>
> Yep, works on ext2/3 the same way.
>

I wonder what the +u option really does? The description is quite cryptic:

> When a file with the `u' attribute set is deleted, its
> contents are saved. This allows the user to ask for its
> undeletion.
>

Where are they saved, how do I undelete them?
I tried it via FTP and via shell and it just removed the directory and
contents like normal with no trace. It says it doesn't work on 2.2 kernels,
but this is a 2.4 kernel.

Kai
--

Conactive Internet Services, Berlin, Germany

Kai Schaetzl wrote:
> Huge schrieb am 25 Apr 2004 17:23:07 GMT:
>
>
>>>Many of our ftp users delete certain necessary directories in their home directories.
>>
>>I suggest that you shrug and go back to whatever you were doing.
>>
>
>
> I suggest that you shrug and contemplate if cryptic answers do any good.

I suggest keeping temper.

- The scenario You describe in Your OP shows that the solution that You
"found" is more than useless, and that You didn't do Your homework.

Hence, Huge's answer was correct when You read it as something like:
"What You want to do is a fairly common problem, and there have been so-
lutions for this. Your error is in the concept, not in the solution of
it."

Anyways, Michael C. Heimig is giving You hints how to produce such
patchwork (and Michael's advises are known for their quality), but that
does not address the problem itself: Your concept simply is the wrong
direction to tackle the issue from, since "Go back!" is a straight, but
correct answer.

Sleep on it. - Come back tomorrow and read Your OP as if You were some-
body else. I am absolutely convinced that then, You will understand Hu-
ge's answer.

OTOHT, Michael pointed You in a good direction when it comes to do what
You want. Conceptionally, though, this is _not_ what You want to do...


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...