Required Directories

Hi all,

I have several servers that the users home directories
contain directories 
that must exists in order for apache and mail to work
correctly.

The users have full read write access to thier home
directories via ftp. (I 
am using proftpd as the backend).

Is there a way (by using either proftpd, or setting sticky
bit, or setting 
the uimmutable flag), that I can prevent the users from
deleting these 
directories, and still retain the ability for my (root run)
scripts to have 
the ability to delete them?

TIA,

-Grant 

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On May 26, 2008, at 7:30 AM, Grant Peel wrote:
> I have several servers that the users home directories
contain  
> directories that must exists in order for apache and
mail to work  
> correctly.
> [ ... ]
> Is there a way (by using either proftpd, or setting
sticky bit, or  
> setting the uimmutable flag), that I can prevent the
users from  
> deleting these directories, and still retain the
ability for my  
> (root run) scripts to have the ability to delete them?

I think that if you make the directories immutable, the
users won't be  
able to create new files under them.  Using root-owned
directories  
which have 1777 permissions would be workable, except that
other users  
could create files under someone else's homedir, also.

It's generally not expected that users would not own the
stuff under  
their homedir, or would not be able to delete their files if
they want  
to, even if doing so would break something.  Normally,
sysadmins code  
their scripts to re-create any missing directory hierarchy
if needed,  
so that if a user manages to shoot themselves in the foot,
the cron  
jobs will be able to provide first aid.

Regards,
-- 
-Chuck

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On Mon, May 26, 2008 at 09:03:29AM -0700, Chuck Swiger
wrote:
> On May 26, 2008, at 7:30 AM, Grant Peel wrote:
>> I have several servers that the users home
directories contain directories 
>> that must exists in order for apache and mail to
work correctly.
>> [ ... ]
>> Is there a way (by using either proftpd, or setting
sticky bit, or setting 
>> the uimmutable flag), that I can prevent the users
from deleting these 
>> directories, and still retain the ability for my
(root run) scripts to 
>> have the ability to delete them?

In the hosting environment I manage, I use UFS flags
extensively.
Checkout chflags(1) manpage, schg and sunlnk flags in
particular.

> It's generally not expected that users would not own
the stuff
> under their homedir, or would not be able to delete
their files
> if they want to, even if doing so would break
something.
> Normally, sysadmins code their scripts to re-create any
missing
> directory hierarchy if needed, so that if a user
manages to
> shoot themselves in the foot, the cron jobs will be
able to
> provide first aid.

I don't know what kind of sysadmins you're talking about,
but,
say, if a hoster did not support files with non-ascii names,
but
let me upload them and then just remove them automatically,
I
would not be happy. Preventive policies work better for me.
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On May 26, 2008, at 9:54 AM, Andrew Pantyukhin wrote:
>> It's generally not expected that users would not
own the stuff
>> under their homedir, or would not be able to delete
their files
>> if they want to, even if doing so would break
something.
>> Normally, sysadmins code their scripts to re-create
any missing
>> directory hierarchy if needed, so that if a user
manages to
>> shoot themselves in the foot, the cron jobs will be
able to
>> provide first aid.
>
> I don't know what kind of sysadmins you're talking
about, but,
> say, if a hoster did not support files with non-ascii
names, but
> let me upload them and then just remove them
automatically, I
> would not be happy.  Preventive policies work better
for me.

Hmm.  While you seem to have written in response to what I'd
said, I'm  
not entirely sure I follow the connection...?

If I were a user who had a need to create non-ASCII
filenames, then I  
would select a platform or hosting environment which could
do exactly  
that, rather than selecting a platform or hosting
environment which  
didn't provide a needed capability.  It took two hops into
Wikipedia  
to dig the following out:

   http://en.wikipedia.org/wiki/Comparison_of_file_sy
stems#Limits

If I were a user that needed to create non-ASCII filenames
and was  
forced to use a platform which didn't support Unicode, well,
I  
wouldn't be happy even if it refused to let me upload my
files without  
renaming them, but sure, I suppose that I agree that it
would be worse  
if it deleted my files after letting me upload them.

I like systems which don't break better than ones which do
and need to  
be fixed.  I like systems which can fix themselves better
than ones  
which can't tolerate recoverable errors and need human
babysitting.   
Lots of people write scripts.  Good scripts perform some
level of  
sanity checking and they set up the environment they need to
work  
instead of assuming that the existing situation is correct. 
They  
might provide guards against excessive concurrency by using
lockfiles,  
they might recognize common modes of failure and deal with
them (even  
if it is by logging an alert for a human and then bailing)
and so forth.

Anyway, using filesystem ACLs or flags to make the
directories un- 
deletable is probably a better solution for Grant's
situation than  
using the sticky bit or immutable flag.

-- 
-Chuck

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"