Re: chmod, chown and user, group
From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 11/20/04
- Next message: Otto Wyss: "Re: chmod, chown and user, group"
- Previous message: Holger Petersen: "Re: chmod, chown and user, group"
- In reply to: Otto Wyss: "Re: chmod, chown and user, group"
- Next in thread: Måns Rullgård: "Re: chmod, chown and user, group"
- Reply: Måns Rullgård: "Re: chmod, chown and user, group"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 20 Nov 2004 23:04:48 +0100
Otto Wyss wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>
> > Otto Wyss wrote:
> > > - can _not_ give it back to user "wyo:src"
> >
> > Seems obvious to me. Is there any part you don't understand?
> >
> Yes, why chown doesn't allow me to give _my_ file to anyone else.
I see. I also wondered about that when I started using
Linux. I had been used to IRIX and Solaris sytems, where
you are allowed to chown your own files. Actually that
can sometimes be inconvenient. I once used 'cp -a' to
copy a tree from somewhere to my own home directory.
Eventually I had to contact a system administrator to
have it removed again, because I didn't have permissions
to do it myself. (Actually in a sticky directory you can
also create links, which you won't be able to remove
yourself).
>
> Race conditons aren't a problem when a user is involved. I.e. if a file
> is shown as deletable but acutally can't, the user has to live with the
> error message if he tries. But it would be nice for a user if he knew
> that a file can't be deleted.
If it is just about showing something to the user, I'd
keep it simple. Some of the special cases like immutable
files I'd avoid, and just let the user see an error
message.
I'd suggest you verify only two things. First of all
that the user have write permissions to the directory.
And in addition to that if the directory is sticky, you
verify that the user is owner of either the directory
or the file.
That should be good enough for displaying in a GUI. I
don't know any distribution that creates immutable
files by default, you have to create them yourself.
Similar for append only directories. And I would not
verify if the files ystem is readonly, there is no
point in showing every single file as being undeletable
just because the directory happen to be on a read only
file system.
In case the program is being run as root, I'd still
use the same rules, and show some files as not being
deletable, even though the restrictions really don't
apply to root. Hopefully showing the file as not
being deletable makes the administrator think an
extra time before deleting a users personal files.
-- Kasper Dupont
- Next message: Otto Wyss: "Re: chmod, chown and user, group"
- Previous message: Holger Petersen: "Re: chmod, chown and user, group"
- In reply to: Otto Wyss: "Re: chmod, chown and user, group"
- Next in thread: Måns Rullgård: "Re: chmod, chown and user, group"
- Reply: Måns Rullgård: "Re: chmod, chown and user, group"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|