Re: can touch(1) readonly files
I see, if I wanted chmod 444 to stop me from touch(1)ing my files, then I would have to give up $ chmod 0 x; ls -l x -- 1 jidanni jidanni 0 2003-05-14 07:38 x listing my files. Ok, over and out.
Re: can touch(1) readonly files
But how can I protect _myself_ from _myself_? I seem to recall in past UNIXes things weren't this bad. $ id uid=1000(jidanni) gid=1000(jidanni) ... $ chmod -w -R ee $ find ee|xargs touch -d 'next year' $ find ee|xargs ls -ld dr-xr-xr-x3 jidanni jidanni 1024 2004-05-13 16:43 ee -r--r--r--1 jidanni jidanni 0 2004-05-13 16:43 ee/ff dr-xr-xr-x2 jidanni jidanni 1024 2004-05-13 16:43 ee/gg I mean I can understand why access times still should be changed, but where is the logic in allowing modification times to be changed? Again, I ask, as a regular user, why can't I protect _myself_ from _myself_ changing file modification times? I wonder just how many of the times in the inode are now gullible. $ uname -a Linux debian 2.4.20-k7 #1 Tue Jan 14 00:29:06 EST 2003 i686 unknown unknown GNU/Linux -- http://jidanni.org/ Taiwan(04)25854780
Re: can touch(1) readonly files
On Tue, May 13, 2003 at 04:59:24PM +0800, Dan Jacobson wrote: But how can I protect _myself_ from _myself_? you cant, since you always can change the permissions of the file back to writeable. Protection from yourself, especially if you are root are extended Unix features (like for example immutable and append only files, RBAC or SELinux). And it is still not a core-utils bug but a property of the Linux kernel. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: can touch(1) readonly files
On Tue, 13 May 2003 21:53, Bernd Eckenfels wrote: On Tue, May 13, 2003 at 04:59:24PM +0800, Dan Jacobson wrote: But how can I protect _myself_ from _myself_? Protection from yourself, especially if you are root are extended Unix features (like for example immutable and append only files, RBAC or SELinux). And it is still not a core-utils bug but a property of the Linux kernel. Bernd is correct. It's a kernel issue. SE Linux allows you to determine who has setattr permission for each file, writing to a file or appending to it will still change the time stamps in the usual fashion, but write and append access can be controlled independantly of read access too. SE Linux allows control over what your processes do. Running a particular program can automatically transition to a different domain with different levels of access to various resources. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: can touch(1) readonly files
Wouter Verhelst [EMAIL PROTECTED] wrote: You can only do that if you have write permissions to the directory the file is in; if not: [EMAIL PROTECTED]:/usr$ touch -d 'next year' doc; ls -ld doc . touch: setting times of `doc': Operation not permitted drwxr-xr-x 16 root root 472 Apr 28 03:21 . drwxr-xr-x2 root root 7568 May 13 02:42 doc Wrong. The error here comes from the fact that, just as described in the documentation, you don't own the file. If I can't write to the directory, but I own the file, I can still make the change: $ mkdir foo $ cd foo $ touch file $ chmod a-w . file $ touch -d 'next year' file $ ll -d . file dr-xr-xr-x2 prj default72 May 13 11:22 . -r--r--r--1 prj default 0 May 13 2004 file This is because those timestamps are saved in the directory inode instead of in the file inode, so closing down permissions on the file won't prevent anyone from tampering with timestamps. No, the file's metadata is stored in its own inode. But its permission bits affect access only to its data, not to its metadata. Metadata is always writable by the owner - otherwise you wouldn't be able to restore your own write access after removing it. paul
Re: can touch(1) readonly files
On Tue, 13 May 2003, Paul Jarc wrote: No, the file's metadata is stored in its own inode. But its permission bits affect access only to its data, not to its metadata. Metadata is always writable by the owner - otherwise you wouldn't be able to restore your own write access after removing it. Reminds me of a bug in the old Icon systems that the schools used in the early 80's or so. The immutable(+i) flag couldn't be removed, even by the superuser because then you'd be modifying the file, which wasn't allowed cause of the +i. So if a student did that on a file, it was there forever until the system was reinstalled. At least, this is what we were told, I suspect somehow the teacher was told this by someone who didn't understand how the +i was supposed to work. Mike
Re: can touch(1) readonly files
On Tue, May 13, 2003 at 11:10:26PM +1000, Russell Coker wrote: Bernd is correct. It's a kernel issue. SE Linux allows you [...] SE Linux allows control [...] Russell, you are such a pimp. ;-) -- G. Branden Robinson| To stay young requires unceasing Debian GNU/Linux | cultivation of the ability to [EMAIL PROTECTED] | unlearn old falsehoods. http://people.debian.org/~branden/ | -- Robert Heinlein pgpH8KIwPv2y9.pgp Description: PGP signature
Re: can touch(1) readonly files
On Tue, May 13, 2003 at 12:05:07PM -0400, Mike Dresser wrote: Reminds me of a bug in the old Icon systems that the schools used in the early 80's or so. The immutable(+i) flag couldn't be removed, even by the superuser because then you'd be modifying the file, which wasn't allowed cause of the +i. well, on linux, you can of course also stop root from removing the immutable flag, after all that is what the flag is all about. it used to be linked to the security level, nowadays one controls it via capabilities. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: can touch(1) readonly files
On Wed, 14 May 2003 04:21, Branden Robinson wrote: On Tue, May 13, 2003 at 11:10:26PM +1000, Russell Coker wrote: Bernd is correct. It's a kernel issue. SE Linux allows you [...] SE Linux allows control [...] Russell, you are such a pimp. ;-) I was provoked. ;) Anyway are you going to be at the Debian mini-conference before LCA? I'll give a talk at the main conference about SE Linux, and maybe a talk at the mini-conf too. Oops, I did it again. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: can touch(1) readonly files
On Tue, May 13, 2003 at 03:10:58AM +0800, Dan Jacobson wrote: Gentlemen, what's the deal where one can change the dates on read-only files? $ chmod -w f; touch -d 'next year' f; ls -l f -r--r--r-- 1 jidanni jidanni 666 2004-05-13 03:02 f You can only do that if you have write permissions to the directory the file is in; if not: [EMAIL PROTECTED]:/usr$ touch -d 'next year' doc; ls -ld doc . touch: setting times of `doc': Operation not permitted drwxr-xr-x 16 root root 472 Apr 28 03:21 . drwxr-xr-x2 root root 7568 May 13 02:42 doc This is because those timestamps are saved in the directory inode instead of in the file inode, so closing down permissions on the file won't prevent anyone from tampering with timestamps. -- wouter at grep dot be An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpHlYLrJQsi4.pgp Description: PGP signature
Re: can touch(1) readonly files
On Tue, May 13, 2003 at 03:02:05AM +0200, Wouter Verhelst wrote: $ chmod -w f; touch -d 'next year' f; ls -l f -r--r--r-- 1 jidanni jidanni 666 2004-05-13 03:02 f You can only do that if you have write permissions to the directory the file is in; if not: which is not quite true: gast:sandbox ls -la drwxrwxrwx2 ecki ecki 28 May 13 03:30 . drwxrwxr-x 217 ecki ecki45056 May 13 03:28 .. -r--r--r--1 ecki ecki0 May 13 03:28 bla -rw-r--r--1 gast ecki0 May 13 03:29 fasel -rw-rw-rw-1 ecki gast0 May 13 03:30 bar gast:sandbox id uid=1010(gast) gid=1010(gast) groups=1010(gast) gast:sandbox touch bla touch: cannot touch `bla': Permission denied gast:sandbox touch fasel gast:sandbox touch bar gast:sandbox ls -la drwxrwxrwx2 ecki ecki 28 May 13 03:30 . drwxrwxr-x 217 ecki ecki45056 May 13 03:28 .. -r--r--r--1 ecki ecki0 May 13 03:28 bla -rw-r--r--1 gast ecki0 May 13 03:32 fasel -rw-rw-rw-1 ecki gast0 May 13 03:32 bar as you can see gast can only touch fasel and bar, but not bla. bla is neighter owned nor writeable by gast, even tough the dir is world-writeable. This is because those timestamps are saved in the directory inode this is because the timestamp and the permission is saved in the file-inode, and the dir entry has no info about that. This is btw a feature of the kernel, not core-utils. Greetings Bernd
