11:14 a.m.
I used to change the owner of some files to root and set them in 444
mode in order to prevent them from modification. And it worked that
way without any issues.
Recently I saw that I can modify/delete any file in my home directory.
Even if it is owned by root and is set as 444. If I'm the owner of the
directory these files are in, I can do whatever I want with them
regardless of their owner and attributes. This is in
kde-dolphin-4.1.4.fc9.
Is this a security bug or change in the kde/dolphin policies? Has
anyone else experienced this?
11:49 a.m.
"Joshua C." <joshuacov(a)googlemail.com> writes:
Recently I saw that I can modify/delete any file in my home
directory.
Even if it is owned by root and is set as 444. If I'm the owner of the
directory these files are in, I can do whatever I want with them
regardless of their owner and attributes.
You can delete or rename anything in a directory you have write
permissions on --- this is not actually affecting the file contents,
only the directory's link. (This has been standard Unix behavior since
the dawn of time or thereabouts. For justification consider the
possibility that your directory entry is only one of several hardlinks
to the file.) If you can modify the file *contents* then it would be
interesting.
regards, tom lane
11:56 a.m.
Hi.
On Mon, 19 Jan 2009 18:14:07 +0100, Joshua C. wrote:
Recently I saw that I can modify/delete any file in my home
directory.
Even if it is owned by root and is set as 444. If I'm the owner of the
directory these files are in, I can do whatever I want with them
regardless of their owner and attributes. This is in
kde-dolphin-4.1.4.fc9.
This has been the way of UNIX since the dawn of time. Deleting a file
is a directory operation, so the permissions on the directory apply,
not the permissions on the file.
You should not be able to modify the file in place, however (but
you could delete it and create a new one, which would be owned by
you and not root).
1:06 p.m.
2009/1/19 Ralf Ertzinger <fedora(a)camperquake.de>:
Hi.
On Mon, 19 Jan 2009 18:14:07 +0100, Joshua C. wrote:
> Recently I saw that I can modify/delete any file in my home directory.
> Even if it is owned by root and is set as 444. If I'm the owner of the
> directory these files are in, I can do whatever I want with them
> regardless of their owner and attributes. This is in
> kde-dolphin-4.1.4.fc9.
This has been the way of UNIX since the dawn of time. Deleting a file
is a directory operation, so the permissions on the directory apply,
not the permissions on the file.
You should not be able to modify the file in place, however (but
you could delete it and create a new one, which would be owned by
you and not root).
I think this concers only deleting a file. But I shouldn't be allowed
to rename it, should I? in kde3 I couldn't delete those files. why?
1:13 p.m.
How can i make a file "readonly" regardless of its place and other
attributes? It should be edit only be root and be placed in whatever
directory it is needed?
3:06 p.m.
On Monday 19 January 2009 02:13:27 pm Joshua C. wrote:
How can i make a file "readonly" regardless of its place
and other
attributes?
chattr -i ./foo
You must have CAP_LINUX_IMMUTABLE to do this which normal users do not. And
you must be on a filesystem, like ext3, which supports immutable files.
-Steve
3:13 p.m.
On 01/19/2009 09:13 PM, Joshua C. wrote:
How can i make a file "readonly" regardless of its place
and other
attributes? It should be edit only be root and be placed in whatever
directory it is needed?
On 01/19/2009 11:07 PM, Steve Grubb wrote:
On Monday 19 January 2009 04:06:26 pm Steve Grubb wrote:
> chattr -i ./foo
>
whoops...actually, chattr +i ./foo
-Steve
actually after chattr +i not even root can modify / delete the file:
[root@wolfy2 tmp]# touch x
[root@wolfy2 tmp]# chattr +i x
[root@wolfy2 tmp]# echo "1" >> x
-bash: x: Permission denied
[root@wolfy2 tmp]# rm x
rm: remove write-protected regular empty file `x'? y
rm: cannot remove `x': Operation not permitted
5:44 a.m.
On Monday 19 January 2009 04:13:09 pm Manuel Wolfshant wrote:
actually after chattr +i not even root can modify / delete the file:
True. But you can chattr -i ./foo and then edit the file remembering to make
it immutable again when you are done editing it. Not as automatic as one
might like, but that's how to do it.
-Steve
4:19 p.m.
Am Dienstag, den 20.01.2009, 06:44 -0500 schrieb Steve Grubb:
On Monday 19 January 2009 04:13:09 pm Manuel Wolfshant wrote:
> actually after chattr +i not even root can modify / delete the file:
True. But you can chattr -i ./foo and then edit the file remembering to make
it immutable again when you are done editing it. Not as automatic as one
might like, but that's how to do it.
-Steve
That would mean a race though. Better to fix directory permissions :)
4:25 p.m.
On Wednesday 21 January 2009 05:19:39 pm nodata wrote:
Am Dienstag, den 20.01.2009, 06:44 -0500 schrieb Steve Grubb:
> On Monday 19 January 2009 04:13:09 pm Manuel Wolfshant wrote:
> > actually after chattr +i not even root can modify / delete the file:
>
> True. But you can chattr -i ./foo and then edit the file remembering to
> make it immutable again when you are done editing it. Not as automatic as
> one might like, but that's how to do it.
That would mean a race though. Better to fix directory permissions :)
The original question was about a file owned by root but readable by others. I
assume 0644 permissions. The root ownership still protects it.
-Steve
12:50 a.m.
2009/1/21 Steve Grubb <sgrubb(a)redhat.com>:
On Wednesday 21 January 2009 05:19:39 pm nodata wrote:
> Am Dienstag, den 20.01.2009, 06:44 -0500 schrieb Steve Grubb:
> > On Monday 19 January 2009 04:13:09 pm Manuel Wolfshant wrote:
> > > actually after chattr +i not even root can modify / delete the file:
> >
> > True. But you can chattr -i ./foo and then edit the file remembering to
> > make it immutable again when you are done editing it. Not as automatic as
> > one might like, but that's how to do it.
>
> That would mean a race though. Better to fix directory permissions :)
The original question was about a file owned by root but readable by others. I
assume 0644 permissions. The root ownership still protects it.
-Steve
This makes part of it useless: If the owner is root but I still can
delete/modify the file (because if dir permissions) then the ownership
doesn't matter. The file was set to 444. The idea was to have a file
that cannot be deleted/modified but only read by everyone regardless
of the directory permissions. And the only suitable answer is to set
it +i.
4:51 a.m.
Joshua C. wrote:
2009/1/21 Steve Grubb <sgrubb(a)redhat.com>:
> On Wednesday 21 January 2009 05:19:39 pm nodata wrote:
>> Am Dienstag, den 20.01.2009, 06:44 -0500 schrieb Steve Grubb:
>>> On Monday 19 January 2009 04:13:09 pm Manuel Wolfshant wrote:
>>>> actually after chattr +i not even root can modify / delete the file:
>>> True. But you can chattr -i ./foo and then edit the file remembering to
>>> make it immutable again when you are done editing it. Not as automatic as
>>> one might like, but that's how to do it.
>> That would mean a race though. Better to fix directory permissions :)
> The original question was about a file owned by root but readable by others. I
> assume 0644 permissions. The root ownership still protects it.
>
> -Steve
>
This makes part of it useless: If the owner is root but I still can
delete/modify the file (because if dir permissions) then the ownership
doesn't matter. The file was set to 444. The idea was to have a file
that cannot be deleted/modified but only read by everyone regardless
of the directory permissions. And the only suitable answer is to set
it +i.
Or make the directory sticky if you must give untrusted users write
access to it and do not want them to be able to unlink or rename one
another's files?
Bryn.
2:39 a.m.
2009/1/19 Steve Grubb <sgrubb(a)redhat.com>:
On Monday 19 January 2009 04:06:26 pm Steve Grubb wrote:
> chattr -i ./foo
whoops...actually, chattr +i ./foo
-Steve
This is what I want. Thanx.
But as I said earlier I had the impression that changing the owner to
root and settting the files in 444 mode would do the work. Back then
when I created those files I tried deleting them and I couldn't.
Therefore I thought it's sufficient. Maybe there was something else
that I did then and cann't remember now?
2:51 a.m.
Joshua C. wrote:
2009/1/19 Steve Grubb <sgrubb(a)redhat.com>:
> On Monday 19 January 2009 04:06:26 pm Steve Grubb wrote:
>
>> chattr -i ./foo
>>
> whoops...actually, chattr +i ./foo
>
> -Steve
>
>
This is what I want. Thanx.
But as I said earlier I had the impression that changing the owner to
root and settting the files in 444 mode would do the work. Back then
when I created those files I tried deleting them and I couldn't.
Therefore I thought it's sufficient. Maybe there was something else
that I did then and cann't remember now?
No, the behaviour that was already described by several posters (and
that you have seen before posting here) is the one implemented by any
Unix since the 60's. You should read the documentation related to file
permission in Unix and think about what each command does and what part
of the filesystem is involved. Basically the directories are files and
the permissions and copy/move/delete operations affect the content of
the "directory files" and therefore it is done according to the
permissions *of the directory*. Reading the content of a specific file
is subject to the access rights related *to the file.*
chattr use extended attributes and is specific to extNfs. a nice other
tool still using extended attributes is setfacl.
5:09 a.m.
Joshua C. wrote:
2009/1/19 Steve Grubb <sgrubb(a)redhat.com>:
> On Monday 19 January 2009 04:06:26 pm Steve Grubb wrote:
>> chattr -i ./foo
> whoops...actually, chattr +i ./foo
>
> -Steve
>
This is what I want. Thanx.
But as I said earlier I had the impression that changing the owner to
root and settting the files in 444 mode would do the work. Back then
when I created those files I tried deleting them and I couldn't.
Therefore I thought it's sufficient. Maybe there was something else
that I did then and cann't remember now?
If this was the case then either the directory you had the files in
had the sticky bit set (causes us to allow unlink/rename if the user
is either the owner of the file, the owner of the containing
directory, or root. Normally used on temporary directories) or
something other than the kernel was preventing you deleting the files.
Regards,
Bryn.
1:14 p.m.
Joshua C. wrote:
2009/1/19 Ralf Ertzinger <fedora(a)camperquake.de>:
> This has been the way of UNIX since the dawn of time. Deleting a file
> is a directory operation, so the permissions on the directory apply,
> not the permissions on the file.
>
> You should not be able to modify the file in place, however (but
> you could delete it and create a new one, which would be owned by
> you and not root).
I think this concers only deleting a file. But I shouldn't be allowed
to rename it, should I? in kde3 I couldn't delete those files. why?
Renaming in unix-like file systems is equivalent to linking the file
into the directory with a new name and then removing the old one.
Still a directory level operation.
Try this:
[bmr@bmr ~]# su -
Password:
[root@bmr bmr]# umask 066
[root@bmr bmr]# touch pony
[root@bmr bmr]# su - bmr
[bmr@bmr ~]$ mv pony not-yours
[bmr@bmr ~]$ ll not-yours
-rw------- 1 root root 0 2009-01-19 19:08 not-yours
[bmr@bmr ~]$ cat not-yours
cat: not-yours: Permission denied
[bmr@bmr ~]$ rm not-yours
rm: remove write-protected regular empty file `not-yours'? y
[bmr@bmr ~]$ ll not-yours
ls: cannot access not-yours: No such file or directory
I can move (rename), or delete, but not access this file.
Regards,
Bryn.
5570
days inactive
5573
days old
16 comments
7 participants
participants (7)
-
Bryn M. Reeves -
Joshua C. -
Manuel Wolfshant -
nodata -
Ralf Ertzinger -
Steve Grubb -
Tom Lane