Everytime I do 'chmod -R a+rX dir' and wonder are there
any executables which I don't want to become world executable,
I think "Whatta hell with this x bit meaning 'can browse'
for dirs?! Who was that clever guy who invented that? Grrrr"
Isn't r sufficient? Can we deprecate x for dirs?
I.e. make it a mirror of r: you set r, you see x set,
you clear r, you see x cleared, set/clear x = nop?
Benefits:
chmod -R go-x dir (ensure there is no executables)
chmod -R a+r dir (make tree world readable)
mount -t vfat -o umask=644 /dev/xxx dir
(I don't want all files to be flagged as executables there)
These commands will do what I want without (sometimes ugly) tricks.
For mount, I can't even see how to do it with current implementation.
What standards will be broken?
Any real loss of functionality apart from compat issues?
--
vda
On Monday 19 November 2001 4:22 pm, vda wrote:
> Everytime I do 'chmod -R a+rX dir' and wonder are there
> any executables which I don't want to become world executable,
> I think "Whatta hell with this x bit meaning 'can browse'
> for dirs?! Who was that clever guy who invented that? Grrrr"
>
> Isn't r sufficient? Can we deprecate x for dirs?
> I.e. make it a mirror of r: you set r, you see x set,
> you clear r, you see x cleared, set/clear x = nop?
>
> Benefits:
> chmod -R go-x dir (ensure there is no executables)
> chmod -R a+r dir (make tree world readable)
> mount -t vfat -o umask=644 /dev/xxx dir
> (I don't want all files to be flagged as executables there)
>
> These commands will do what I want without (sometimes ugly) tricks.
> For mount, I can't even see how to do it with current implementation.
>
> What standards will be broken?
> Any real loss of functionality apart from compat issues?
The R and X bits on directories have different meanings. Watch:
$ mkdir test
$ echo content > test/file
$ chmod a-r test
$ ls test
ls: test: permission denied
$ cat test/file
content
$ chmod a=r test
$ ls test
ls: test/file: Permission denied
In short, the X bit allows you to access the contents of the directory, while
R allows you to LIST those contents. There are valid uses for X only
directories (i.e. users are not allowed to list the contents, only to access
them directly by name). R-only directories make little sense, as you can see
from the transcript above :)
James.
On Mon, 19 Nov 2001, vda wrote:
> Everytime I do 'chmod -R a+rX dir' and wonder are there
> any executables which I don't want to become world executable,
> I think "Whatta hell with this x bit meaning 'can browse'
> for dirs?! Who was that clever guy who invented that? Grrrr"
>
> Isn't r sufficient? Can we deprecate x for dirs?
> I.e. make it a mirror of r: you set r, you see x set,
> you clear r, you see x cleared, set/clear x = nop?
See UNIX FAQ. Ability to read != ability to lookup.
Trivial example: you have a directory with a bunch of subdirectories.
You want owners of subdirectories to see them. You don't want them
to _know_ about other subdirectories.
--
BUGS
There's no perm option for the naughty bits.
BSD chmod(1)
On Monday 19 November 2001 14:36, James A Sutherland wrote:
> On Monday 19 November 2001 4:22 pm, vda wrote:
> > Everytime I do 'chmod -R a+rX dir' and wonder are there
> > any executables which I don't want to become world executable,
> > I think "Whatta hell with this x bit meaning 'can browse'
> > for dirs?! Who was that clever guy who invented that? Grrrr"
> >
> > Isn't r sufficient? Can we deprecate x for dirs?
> > I.e. make it a mirror of r: you set r, you see x set,
> > you clear r, you see x cleared, set/clear x = nop?
> >
> > Benefits:
> > chmod -R go-x dir (ensure there is no executables)
> > chmod -R a+r dir (make tree world readable)
> > mount -t vfat -o umask=644 /dev/xxx dir
> > (I don't want all files to be flagged as executables there)
> >
> > These commands will do what I want without (sometimes ugly) tricks.
> > For mount, I can't even see how to do it with current implementation.
> >
> > What standards will be broken?
> > Any real loss of functionality apart from compat issues?
> The R and X bits on directories have different meanings. Watch:
I know. I'd like to hear anybody who have a directory with r!=x
on purpose (and quite curious on that purpose). UNIX gugus, anybody?
> $ mkdir test
> $ echo content > test/file
> $ chmod a-r test
> $ ls test
> ls: test: permission denied
> $ cat test/file
> content
> $ chmod a=r test
> $ ls test
> ls: test/file: Permission denied
Hmm... I do actually tested this and last command succeeds
(shows dir contents). You probably meant cat test/file, not ls...
> In short, the X bit allows you to access the contents of the directory,
> while R allows you to LIST those contents. There are valid uses for X only
> directories (i.e. users are not allowed to list the contents, only to
> access them directly by name). R-only directories make little sense, as you
> can see from the transcript above :)
On Monday 19 November 2001 14:46, Alexander Viro wrote:
> On Mon, 19 Nov 2001, vda wrote:
> > Everytime I do 'chmod -R a+rX dir' and wonder are there
> > any executables which I don't want to become world executable,
> > I think "Whatta hell with this x bit meaning 'can browse'
> > for dirs?! Who was that clever guy who invented that? Grrrr"
> >
> > Isn't r sufficient? Can we deprecate x for dirs?
> > I.e. make it a mirror of r: you set r, you see x set,
> > you clear r, you see x cleared, set/clear x = nop?
>
> See UNIX FAQ. Ability to read != ability to lookup.
>
> Trivial example: you have a directory with a bunch of subdirectories.
> You want owners of subdirectories to see them. You don't want them
> to _know_ about other subdirectories.
Security through obscurity, that is.
Do you have even a single dir on your boxes with r!=x?
--
vda
On Mon, Nov 19, 2001 at 04:58:38PM +0000, vda wrote:
> I know. I'd like to hear anybody who have a directory with r!=x
> on purpose (and quite curious on that purpose). UNIX gugus, anybody?
ftp://.../incoming
Tim.
*/
On Mon, 2001-11-19 at 12:03, vda wrote:
> On Monday 19 November 2001 14:46, Alexander Viro wrote:
> > On Mon, 19 Nov 2001, vda wrote:
> > > Everytime I do 'chmod -R a+rX dir' and wonder are there
> > > any executables which I don't want to become world executable,
> > > I think "Whatta hell with this x bit meaning 'can browse'
> > > for dirs?! Who was that clever guy who invented that? Grrrr"
> > >
> > > Isn't r sufficient? Can we deprecate x for dirs?
> > > I.e. make it a mirror of r: you set r, you see x set,
> > > you clear r, you see x cleared, set/clear x = nop?
> >
> > See UNIX FAQ. Ability to read != ability to lookup.
> >
> > Trivial example: you have a directory with a bunch of subdirectories.
> > You want owners of subdirectories to see them. You don't want them
> > to _know_ about other subdirectories.
>
> Security through obscurity, that is.
>
> Do you have even a single dir on your boxes with r!=x?
I've seen this a lot with html directories for web servers.
On 19-Nov-2001 vda wrote:
> Everytime I do 'chmod -R a+rX dir' and wonder are there
> any executables which I don't want to become world executable,
> I think "Whatta hell with this x bit meaning 'can browse'
> for dirs?! Who was that clever guy who invented that? Grrrr"
>
> Isn't r sufficient? Can we deprecate x for dirs?
> I.e. make it a mirror of r: you set r, you see x set,
> you clear r, you see x cleared, set/clear x = nop?
>
> Benefits:
> chmod -R go-x dir (ensure there is no executables)
> chmod -R a+r dir (make tree world readable)
> mount -t vfat -o umask=644 /dev/xxx dir
> (I don't want all files to be flagged as executables there)
This is all userspace:
find . -type d -exec chmod a+rx {} \;
make an alias for it and stop considering changing one of the earliest
unix standards. I'm sure if you really want this policy you can write your
own chmod executable.
me
--
me
On Mon, 19 Nov 2001, vda wrote:
> > Trivial example: you have a directory with a bunch of subdirectories.
> > You want owners of subdirectories to see them. You don't want them
> > to _know_ about other subdirectories.
>
> Security through obscurity, that is.
Huh? By the same logics /etc/shadow is security through obscurity -
after all, you can try all possible passwords one by one. Ability to use
key != ability to see valid keys.
> Do you have even a single dir on your boxes with r!=x?
Yes.
Please, go to rtfm.mit.edu and find the UNIX FAQ there. Then read the
relevant parts.
On 19-Nov-2001 vda wrote:
> Security through obscurity, that is.
>
> Do you have even a single dir on your boxes with r!=x?
IIRC, postfix depends on it.
--
me
On Mon, 19 Nov 2001, Tim Waugh wrote:
> On Mon, Nov 19, 2001 at 04:58:38PM +0000, vda wrote:
>
> > I know. I'd like to hear anybody who have a directory with r!=x
> > on purpose (and quite curious on that purpose). UNIX gugus, anybody?
>
> ftp://.../incoming
>
> Tim.
> */
>
It doesn't make any difference if it's useful. It is a de-facto
standard. Therefore, it must exist. It's just like all the stuff
in the C runtime library you never use like bcopy()!
If everybody in the world wanted to get rid of that dumb bit,
you still couldn't do it. It needs to exists for no other reason
than it has existed.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
On Mon, 19 Nov 2001, vda wrote:
> On Monday 19 November 2001 14:46, Alexander Viro wrote:
> > On Mon, 19 Nov 2001, vda wrote:
> > > Everytime I do 'chmod -R a+rX dir' and wonder are there
> > > any executables which I don't want to become world executable,
> > > I think "Whatta hell with this x bit meaning 'can browse'
> > > for dirs?! Who was that clever guy who invented that? Grrrr"
> > >
> > > Isn't r sufficient? Can we deprecate x for dirs?
> > > I.e. make it a mirror of r: you set r, you see x set,
> > > you clear r, you see x cleared, set/clear x = nop?
> >
> > See UNIX FAQ. Ability to read != ability to lookup.
> >
> > Trivial example: you have a directory with a bunch of subdirectories.
> > You want owners of subdirectories to see them. You don't want them
> > to _know_ about other subdirectories.
>
> Security through obscurity, that is.
>
> Do you have even a single dir on your boxes with r!=x?
> --
/home/user/public_html
Apache needs to be able to access public_html but you really don't want
other users browsing your home dir.
This is in fact a VERY COMMON SETUP and several distros even set things up
that way by default.
On top of that your proposed change would make linux diffrent from every
other Unix like OS making life harder for those of us who admin/code for
several diffrent OS.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
On Monday 19 November 2001 15:12, Mathijs Mohlmann wrote:
> On 19-Nov-2001 vda wrote:
> > Everytime I do 'chmod -R a+rX dir' and wonder are there
> > any executables which I don't want to become world executable,
> > I think "Whatta hell with this x bit meaning 'can browse'
> > for dirs?! Who was that clever guy who invented that? Grrrr"
> >
> > Isn't r sufficient? Can we deprecate x for dirs?
> > I.e. make it a mirror of r: you set r, you see x set,
> > you clear r, you see x cleared, set/clear x = nop?
> >
> > Benefits:
> > chmod -R go-x dir (ensure there is no executables)
> > chmod -R a+r dir (make tree world readable)
> > mount -t vfat -o umask=644 /dev/xxx dir
> > (I don't want all files to be flagged as executables there)
>
> This is all userspace:
> find . -type d -exec chmod a+rx {} \;
>
> make an alias for it and stop considering changing one of the earliest
> unix standards. I'm sure if you really want this policy you can write your
> own chmod executable.
Well, I think you're right. I still think that overloading one bit to have
two meanings (exec for file, browse for dir) was a bad idea, but it looks
unsurmountable now to change that. Amount (and tone) of replies proves this.
chmod/mount/.../... workarounds is the best we can do now.
chmod -R [ugoa]+R dir - set r for files, rx for dirs
chmod -R [ugoa]-R dir - remove r for files, rx for dirs
^
mount -t vfat -o umask=644,udmask=755 /dev/hdc1 /mnt/hdc1
^^^^^^^^^^
--
vda
On Monday 19 November 2001 4:58 pm, vda wrote:
> On Monday 19 November 2001 14:36, James A Sutherland wrote:
> > $ mkdir test
> > $ echo content > test/file
> > $ chmod a-r test
> > $ ls test
> > ls: test: permission denied
> > $ cat test/file
> > content
> > $ chmod a=r test
> > $ ls test
> > ls: test/file: Permission denied
>
> Hmm... I do actually tested this and last command succeeds
> (shows dir contents). You probably meant cat test/file, not ls...
Nope, ls.
[james@dax p2i]$ ls test
ls: test/file: Permission denied
[james@dax p2i]$ ls -l test
ls: test/file: Permission denied
total 0
(There is something incredibly stupid about the first one: ls is unable to,
er, read the name of the named file?!)
Anyway, as Al Viro has pointed out, R!=X. It's been like that for a very long
time, it's deliberate, not a misfeature, and it's staying like that for the
foreseeable future.
James.
vda <[email protected]> said:
[...]
> Do you have even a single dir on your boxes with r!=x?
Directories /dev, /lib, /bin, /etc under FTP home are --x. I'd do the same
with cgi-bin et al for WWW...
Some FTP sites (f.ex. ftp.sendmail.org) have limited distribution
prereleases under an unreadable directory (--x).
-wx is used for anonymous uploading under FTP
It certainly has its uses. If you wanted to _really_ lock down a box, you'd
start by doing the same --x game for some critical directories.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Monday 19 November 2001 16:00, you wrote:
> On Monday 19 November 2001 4:58 pm, vda wrote:
> > On Monday 19 November 2001 14:36, James A Sutherland wrote:
> > > $ mkdir test
> > > $ echo content > test/file
> > > $ chmod a-r test
> > > $ ls test
> > > ls: test: permission denied
> > > $ cat test/file
> > > content
> > > $ chmod a=r test
> > > $ ls test
> > > ls: test/file: Permission denied
> >
> > Hmm... I do actually tested this and last command succeeds
> > (shows dir contents). You probably meant cat test/file, not ls...
>
> Nope, ls.
>
> [james@dax p2i]$ ls test
> ls: test/file: Permission denied
> [james@dax p2i]$ ls -l test
> ls: test/file: Permission denied
> total 0
Looks like we have different ls :-). Mine lists 'r only' dir with no problem.
> Anyway, as Al Viro has pointed out, R!=X. It's been like that for a very
> long time, it's deliberate, not a misfeature, and it's staying like that
> for the foreseeable future.
Yes, I see... All I can do is to add workarounds (ok,ok, 'support')
to chmod and friends:
chmod -R a+R dir - sets r for files and rx for dirs
--
vda
vda <[email protected]> said:
[...]
> > [james@dax p2i]$ ls test
> > ls: test/file: Permission denied
> > [james@dax p2i]$ ls -l test
> > ls: test/file: Permission denied
> > total 0
>
> Looks like we have different ls :-). Mine lists 'r only' dir with no
> problem.
Probably some alias. "/bin/ls test" should work, "/bin/ls -l test" won't.
> > Anyway, as Al Viro has pointed out, R!=X. It's been like that for a very
> > long time, it's deliberate, not a misfeature, and it's staying like that
> > for the foreseeable future.
>
> Yes, I see... All I can do is to add workarounds (ok,ok, 'support')
> to chmod and friends:
>
> chmod -R a+R dir - sets r for files and rx for dirs
X sets x for dirs, leaves files alone.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
vda <[email protected]>
>
> On Monday 19 November 2001 14:36, James A Sutherland wrote:
> > On Monday 19 November 2001 4:22 pm, vda wrote:
> > > Everytime I do 'chmod -R a+rX dir' and wonder are there
> > > any executables which I don't want to become world executable,
> > > I think "Whatta hell with this x bit meaning 'can browse'
> > > for dirs?! Who was that clever guy who invented that? Grrrr"
> > >
> > > Isn't r sufficient? Can we deprecate x for dirs?
> > > I.e. make it a mirror of r: you set r, you see x set,
> > > you clear r, you see x cleared, set/clear x = nop?
> > >
> > > Benefits:
> > > chmod -R go-x dir (ensure there is no executables)
> > > chmod -R a+r dir (make tree world readable)
> > > mount -t vfat -o umask=644 /dev/xxx dir
> > > (I don't want all files to be flagged as executables there)
> > >
> > > These commands will do what I want without (sometimes ugly) tricks.
> > > For mount, I can't even see how to do it with current implementation.
> > >
> > > What standards will be broken?
> > > Any real loss of functionality apart from compat issues?
>
> > The R and X bits on directories have different meanings. Watch:
>
> I know. I'd like to hear anybody who have a directory with r!=x
> on purpose (and quite curious on that purpose). UNIX gugus, anybody?
It's used to hide files in anonymous FTP for for one. It prevents you from
retrieving files that you don't know the name of. Yes, a brute force attempt
to open MAY work to find the unknown file, it will take a long time, and you
are most likely to be detected. The anonymous FTP use is usually in an incoming
directory - the files are put there from remote individuals, and are hidden
(unless someone is a good guesser/or a poor name chosen) until the
administrator examines/moves them.
>
> > $ mkdir test
> > $ echo content > test/file
> > $ chmod a-r test
> > $ ls test
> > ls: test: permission denied
> > $ cat test/file
> > content
> > $ chmod a=r test
> > $ ls test
> > ls: test/file: Permission denied
>
> Hmm... I do actually tested this and last command succeeds
> (shows dir contents). You probably meant cat test/file, not ls...
>
> > In short, the X bit allows you to access the contents of the directory,
> > while R allows you to LIST those contents. There are valid uses for X only
> > directories (i.e. users are not allowed to list the contents, only to
> > access them directly by name). R-only directories make little sense, as you
> > can see from the transcript above :)
It's there for consistancy/simplisity. Mode bits for directories are treated
the same as they are for any other type of file.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
>
>
>>I know. I'd like to hear anybody who have a directory with r!=x
>>on purpose (and quite curious on that purpose). UNIX gugus, anybody?
>>
>
>It's used to hide files in anonymous FTP for for one. It prevents you from
>retrieving files that you don't know the name of. Yes, a brute force attempt
>to open MAY work to find the unknown file, it will take a long time, and you
>are most likely to be detected. The anonymous FTP use is usually in an incoming
>directory - the files are put there from remote individuals, and are hidden
>(unless someone is a good guesser/or a poor name chosen) until the
>administrator examines/moves them.
>
I use it for more than just ftp. I chmod 710 ~ and have ~ in the
web/email groups. It stops prying eyes unless they know what the
filename is.
David
On Monday 19 November 2001 16:44, Horst von Brand wrote:
> > > Anyway, as Al Viro has pointed out, R!=X. It's been like that for a
> > > very long time, it's deliberate, not a misfeature, and it's staying
> > > like that for the foreseeable future.
> >
> > Yes, I see... All I can do is to add workarounds (ok,ok, 'support')
> > to chmod and friends:
> >
> > chmod -R a+R dir - sets r for files and rx for dirs
>
> X sets x for dirs, leaves files alone.
Hmm... yes this is one of such workarounds already implemented.
But it is not very good for my example:
X sets x for dirs *and* for files with x set for any of u,g,o.
# chmod -R a+rX dir
will make any executables (even root only) world-executable.
That's why I'd like to add new flag to chmod: R.
--
vda
On Monday 19 November 2001 4:44 pm, Horst von Brand wrote:
> vda <[email protected]> said:
>
> [...]
>
> > > [james@dax p2i]$ ls test
> > > ls: test/file: Permission denied
> > > [james@dax p2i]$ ls -l test
> > > ls: test/file: Permission denied
> > > total 0
> >
> > Looks like we have different ls :-). Mine lists 'r only' dir with no
> > problem.
>
> Probably some alias. "/bin/ls test" should work, "/bin/ls -l test" won't.
Correct: my default ls is trying to stat the files to pick a pretty color for
them...
> > > Anyway, as Al Viro has pointed out, R!=X. It's been like that for a
> > > very long time, it's deliberate, not a misfeature, and it's staying
> > > like that for the foreseeable future.
> >
> > Yes, I see... All I can do is to add workarounds (ok,ok, 'support')
> > to chmod and friends:
> >
> > chmod -R a+R dir - sets r for files and rx for dirs
>
> X sets x for dirs, leaves files alone.
Which sounds like exactly the behaviour the original poster wanted, AFAICS?
James.
On Mon, 19 Nov 2001, vda wrote:
> I know. I'd like to hear anybody who have a directory with r!=x
> on purpose (and quite curious on that purpose). UNIX gugus, anybody?
When you have a web server running with user homepages in $HOME/www or
similar, users need to have x set for the web server to serve their pages,
but some users may not want all other users to see what files they have.
Those people will have --x permission for other on their $HOME.
--
Ciao, Pascal
-<[ [email protected], netmail 2:241/215.72, home http://cobol.cjb.net/) ]>-
On Monday 19 November 2001 17:24, James A Sutherland wrote:
> > > Yes, I see... All I can do is to add workarounds (ok,ok, 'support')
> > > to chmod and friends:
> > >
> > > chmod -R a+R dir - sets r for files and rx for dirs
> >
> > X sets x for dirs, leaves files alone.
>
> Which sounds like exactly the behaviour the original poster wanted, AFAICS?
Yes, that sounds like the behaviour I want. But X flag does not do that.
Sorry.
James, I don't like flame wars. Lets ask ourself: does this thread have any
useful results? Unfortunately, not many.
Patches for chmod source would be better. Perhaps I should do that...
Let's refrain from "you're fool... go read manpage" type
discussions. Not productive.
--
vda
vda <[email protected]> said:
> On Monday 19 November 2001 16:44, Horst von Brand wrote:
[...]
> > X sets x for dirs, leaves files alone.
> Hmm... yes this is one of such workarounds already implemented.
> But it is not very good for my example:
> X sets x for dirs *and* for files with x set for any of u,g,o.
>
> # chmod -R a+rX dir
>
> will make any executables (even root only) world-executable.
That's what you are asking for...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
vda wrote:
> I know. I'd like to hear anybody who have a directory with r!=x
> on purpose (and quite curious on that purpose). UNIX gugus, anybody?
Absolutely -
It is quite common to have dirs with perms 711 -
This allows arbitrary users to copy specific files
from such a directory, but does not allow them to
cd into that directory or to browse it.
Losing that distinction would be crippling.
cu
jjs
On Monday 19 November 2001 7:39 pm, vda wrote:
> On Monday 19 November 2001 17:24, James A Sutherland wrote:
> > > > Yes, I see... All I can do is to add workarounds (ok,ok, 'support')
> > > > to chmod and friends:
> > > >
> > > > chmod -R a+R dir - sets r for files and rx for dirs
> > >
> > > X sets x for dirs, leaves files alone.
> >
> > Which sounds like exactly the behaviour the original poster wanted,
> > AFAICS?
>
> Yes, that sounds like the behaviour I want. But X flag does not do that.
> Sorry.
Oh? I just checked, and X *does* set the x bit on directories only, leaving
files unaffected. What's wrong with that? Does it not do this on your system?
Or do you want some other behaviour?
> James, I don't like flame wars. Lets ask ourself: does this thread have any
> useful results? Unfortunately, not many.
> Patches for chmod source would be better. Perhaps I should do that...
Patch it to do what? The current behaviour seems to me to be what you want...
> Let's refrain from "you're fool... go read manpage" type
> discussions. Not productive.
Agreed - if the question were covered in a manpage, I doubt there would be a
thread here on LKML about it :)
James.
[email protected] (James A Sutherland) wrote on 19.11.01 in <[email protected]>:
> [james@dax p2i]$ ls test
> ls: test/file: Permission denied
> [james@dax p2i]$ ls -l test
> ls: test/file: Permission denied
> total 0
>
> (There is something incredibly stupid about the first one: ls is unable to,
> er, read the name of the named file?!)
Try 'ls --color=none'. Then go read 'info ls'.
MfG Kai
On Monday 19 November 2001 20:39, vda wrote:
> Patches for chmod source would be better. Perhaps I should do that...
> Let's refrain from "you're fool... go read manpage" type
> discussions. Not productive.
Calling you a fool would certainly be stupid, however you are arguing
about a feature that Unix filesystems have had since the beginning of time
and that every sysadmin uses quite frequently (as described in several
posts) so you're not going to get much support, not on LKML at least. ;-)
Patching chmod to add a new option would save some typing once in a while,
but if you find yourself doing such chmod'ing often the very obvious
solution (which was already proposed) is
find -type d -exec chmod +x \{\} \;
eventually wrapped in a script, alias or whatever. That's what Unices are
good for: you can easily build new utilities by combining existing ones,
no need to patch anything.
Some might agree that assigning different purposes to the 'x' bit for
files and directories might be confusing, but there's a fix for that too:
just think "eXplore" instead of "eXecute" when you look at directories.
Now one could start arguing about the setgid bit too, and that's more
dangerous than the execute/explore bit, but again, it always worked that
way and it ain't gonna change anytime soon.
--
Ciao,
Flavio Stanchina
Trento - Italy
"The best defense against logic is ignorance."
http://spazioweb.inwind.it/fstanchina/
vda wrote:
>On Monday 19 November 2001 14:46, Alexander Viro wrote:
>
>>On Mon, 19 Nov 2001, vda wrote:
>>
>>>[...]
>>>
>>See UNIX FAQ. Ability to read != ability to lookup.
>>
>>Trivial example: you have a directory with a bunch of subdirectories.
>>You want owners of subdirectories to see them. You don't want them
>>to _know_ about other subdirectories.
>>
>
>Security through obscurity, that is.
>
Security through obscurity is about hiding protection measures taken not
about hiding sensible data...
Hiding sensible data is the main protection measures' purpose :-)
One single example :
Would you want to publish the exhaustive list of locations were your
credit card number may be stored (even though it *should* be perfectly
secure) or keep it hiden from public eyes ?
This is mainly OT on linux-kernel now. Feel free to mail me directly for
future exchanges.
vda writes:
> I think "Whatta hell with this x bit meaning 'can browse'
> for dirs?! Who was that clever guy who invented that? Grrrr"
>
> Isn't r sufficient? Can we deprecate x for dirs?
> I.e. make it a mirror of r: you set r, you see x set,
> you clear r, you see x cleared, set/clear x = nop?
That won't fly, but maybe NFSv4 permissions will. Then at
least you could specify "search" or "traverse" permission,
neither of which will affect regular files.
On Monday 19 November 2001 18:14, Horst von Brand wrote:
> vda <[email protected]> said:
> > On Monday 19 November 2001 16:44, Horst von Brand wrote:
>
> [...]
>
> > > X sets x for dirs, leaves files alone.
> >
> > Hmm... yes this is one of such workarounds already implemented.
> > But it is not very good for my example:
> > X sets x for dirs *and* for files with x set for any of u,g,o.
> >
> > # chmod -R a+rX dir
> >
> > will make any executables (even root only) world-executable.
>
> That's what you are asking for...
?!
I'm asking for ability to make a tree _world-readable_ (and
browsable), i.e. a+r on files and a+rx on dirs.
There is currently no chmod flag which will do that.
--
vda
On Monday 19 November 2001 19:07, James A Sutherland wrote:
> On Monday 19 November 2001 7:39 pm, vda wrote:
> > On Monday 19 November 2001 17:24, James A Sutherland wrote:
> > > > > Yes, I see... All I can do is to add workarounds (ok,ok, 'support')
> > > > > to chmod and friends:
> > > > >
> > > > > chmod -R a+R dir - sets r for files and rx for dirs
> > > >
> > > > X sets x for dirs, leaves files alone.
> > >
> > > Which sounds like exactly the behaviour the original poster wanted,
> > > AFAICS?
> >
> > Yes, that sounds like the behaviour I want. But X flag does not do that.
> > Sorry.
>
> Oh? I just checked, and X *does* set the x bit on directories only, leaving
> files unaffected. What's wrong with that? Does it not do this on your
> system? Or do you want some other behaviour?
I just checked it too (not olny read the manpage but conducted an
experiment). If a file has any of three x bits set, chmod a+X will
set all three x bits, making it world-executable.
That is not what I want. I want to make whole tree world-readable (and
browsable), i.e. a+r on files and a+rx on dirs. There is no chmod flag
which will do that.
[I'd like to take this silliness off the lkml but [email protected]
rejects my direct emails:
----- Transcript of session follows -----
... while talking to navy.csi.cam.ac.uk.:
>>> RCPT To:<[email protected]>
<<< 550 mail from 195.66.192.167 rejected: administrative prohibition (host
is blacklisted)
550 5.1.1 <[email protected]>... User unknown ]
--
vda
At 12:58 20/11/01, vda wrote:
>I'm asking for ability to make a tree _world-readable_ (and
>browsable), i.e. a+r on files and a+rx on dirs.
>There is currently no chmod flag which will do that.
So what? The following two commands do exactly that:
find . -type d -exec chmod a+rx "{}" \;
find . -type f -exec chmod a+r "{}" \;
Just stick them in a shell script and call the script chmod-world-readable
and stop complaining...
You would obviously want to change the "." to be $1 so it is the 1st
argument to the script...
It will be a bit slow and can be optimized endlessly but it will do the
trick and you probably won't be running it that often so speed is not an
issue... And if it is then grab the chmod sources and add the wanted
functionality with a new swich and be done with it.
This is WAY Off Topic for Linux kernel!
Best regards,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
On Tue, 20 Nov 2001, Anton Altaparmakov wrote:
> So what? The following two commands do exactly that:
>
> find . -type d -exec chmod a+rx "{}" \;
> find . -type f -exec chmod a+r "{}" \;
>
> Just stick them in a shell script and call the script chmod-world-readable
> and stop complaining...
Just don't do that if that subtree contains a directory writable to somebody
else. There is a nasty attack here.
Think what happens if root does that for /tmp/foo and some luser has write
permissions on /tmp/foo/bar. There is a window between execve() on chmod(1)
and call of chmod(2) and during that window luser can replace /tmp/foo/bar/baz
to symlink to /etc and leave root doing chmod("/tmp/foo/bar/baz/shadow", 0744);
Not that chmod(1) was any better at that... It should've been keeping
all chain between the root of subtree and parent of file we currently
handling opened and do open()/fstat()/fchdir() to go down and fchdir()
to go up. Then all calls of chmod(2) would be for files in current
directory, which prevents symlink attacks.
Moral: think _very_ hard when you write any tree-walking code that will
ever be used on a tree writable to somebody else.
At 12:01 20/11/01, Alexander Viro wrote:
>On Tue, 20 Nov 2001, Anton Altaparmakov wrote:
> > So what? The following two commands do exactly that:
> >
> > find . -type d -exec chmod a+rx "{}" \;
> > find . -type f -exec chmod a+r "{}" \;
> >
> > Just stick them in a shell script and call the script chmod-world-readable
> > and stop complaining...
>
>Just don't do that if that subtree contains a directory writable to somebody
>else. There is a nasty attack here.
Ok. But I assume the application for this is something like /usr/share to
which noone would have write privileges to (I would hope). I doubt anyone
would want to run it on /home... and if they do they most likely don't care
about security too much anyway... (-;
>Think what happens if root does that for /tmp/foo and some luser has write
>permissions on /tmp/foo/bar. There is a window between execve() on chmod(1)
>and call of chmod(2) and during that window luser can replace /tmp/foo/bar/baz
>to symlink to /etc and leave root doing chmod("/tmp/foo/bar/baz/shadow",
>0744);
>
>Not that chmod(1) was any better at that... It should've been keeping
>all chain between the root of subtree and parent of file we currently
>handling opened and do open()/fstat()/fchdir() to go down and fchdir()
>to go up. Then all calls of chmod(2) would be for files in current
>directory, which prevents symlink attacks.
>
>Moral: think _very_ hard when you write any tree-walking code that will
>ever be used on a tree writable to somebody else.
Point taken. I will keep it in mind when implementing ACLs (and ACL
inheritance in particular) in NTFS. That will involve walking back to the
volume's root to establish the inherited rights... which might perhaps lend
itself to simillar abuse.
Cheers,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
Please forgive me if I overlooked the message that
already said this, but ...
James Sutherland wrote that "There are valid uses for
X only directories (i.e. users are not allowed to list
the contents, only to access them directly by name).
R-only directories make little sense". Then there
followed a long discussion about the utility of "--x"
directories. (I agree that they aren't a very good
idea, since an explorable directory can be "listed" by
trial and error on the filenames within it.)
However, a decent reason for having separate r and x
is that "r--" directories _do_ make sense. When a
directory is "r--", its contents can be _listed_ but the
directory cannot be browsed. Observe: // Thomas Hood
jdthood@thanatos:~/tmp$ ls -l
total 8
drwxr-xr-x 2 jdthood jdthood 4096 Nov 20 10:59 ./
drwx------ 89 jdthood jdthood 4096 Nov 20 10:55 ../
jdthood@thanatos:~/tmp$ mkdir --mode=777 test
jdthood@thanatos:~/tmp$ ls -l
total 12
drwxr-xr-x 3 jdthood jdthood 4096 Nov 20 10:59 ./
drwx------ 89 jdthood jdthood 4096 Nov 20 10:55 ../
drwxrwxrwx 2 jdthood jdthood 4096 Nov 20 10:59 test/
jdthood@thanatos:~/tmp$ touch test/1
jdthood@thanatos:~/tmp$ touch test/2
jdthood@thanatos:~/tmp$ ls -l . test
.:
total 12
drwxr-xr-x 3 jdthood jdthood 4096 Nov 20 10:59 ./
drwx------ 89 jdthood jdthood 4096 Nov 20 10:55 ../
drwxrwxrwx 2 jdthood jdthood 4096 Nov 20 10:59 test/
test:
total 8
drwxrwxrwx 2 jdthood jdthood 4096 Nov 20 10:59 ./
drwxr-xr-x 3 jdthood jdthood 4096 Nov 20 10:59 ../
-rw-r--r-- 1 jdthood jdthood 0 Nov 20 10:59 1
-rw-r--r-- 1 jdthood jdthood 0 Nov 20 10:59 2
jdthood@thanatos:~/tmp$ chmod ugo-x test
jdthood@thanatos:~/tmp$ ls -l . test
.:
total 12
drwxr-xr-x 3 jdthood jdthood 4096 Nov 20 10:59 ./
drwx------ 89 jdthood jdthood 4096 Nov 20 10:55 ../
drw-rw-rw- 2 jdthood jdthood 4096 Nov 20 10:59 test/
ls: test/.: Permission denied
ls: test/..: Permission denied
ls: test/1: Permission denied
ls: test/2: Permission denied
test:
total 0
jdthood@thanatos:~/tmp$ chmod ugo-r test
jdthood@thanatos:~/tmp$ ls -l . test
.:
total 12
drwxr-xr-x 3 jdthood jdthood 4096 Nov 20 10:59 ./
drwx------ 89 jdthood jdthood 4096 Nov 20 10:55 ../
d-w--w--w- 2 jdthood jdthood 4096 Nov 20 10:59 test/
ls: test: Permission denied
On Tue, Nov 20, 2001 at 11:20:06AM +0000, Anton Altaparmakov wrote:
> find . -type d -exec chmod a+rx "{}" \;
> find . -type f -exec chmod a+r "{}" \;
That is a bit inefficient though. It results in one fork/exec pair for
each file and each directory.
A better solution is to use find | xargs
find /path/to/dir -type d -print0 | xargs -0 chmod a+rx
find /path/to/dir -type f -print0 | xargs -0 chmod a+r
That way, xargs bunches up the arguments into as many arguments as chmod
can handle, and calls it fewer times.
The -print0 and -0 are GNU extensions to handle spaces in names.
mrc
--
Mike Castle [email protected] http://www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
On Tue, 20 Nov 2001, Mike Castle wrote:
> find /path/to/dir -type d -print0 | xargs -0 chmod a+rx
> find /path/to/dir -type f -print0 | xargs -0 chmod a+r
>
> That way, xargs bunches up the arguments into as many arguments as chmod
> can handle, and calls it fewer times.
>
> The -print0 and -0 are GNU extensions to handle spaces in names.
That's even worse than original. You've got a very wide race here -
think what happens if luser does
cd /path/to/dir/something/writable/to/luser
mkdir bar
mkdir baz
for i in `seq 1 500`; do
mkdir bar/$i
touch bar/$i/shadow
ln -sf /etc baz/$i
done
before you start, then waits for first chmod a+r and does
mv bar quux; mv baz bar
leaving you with very interesting results. It's much wider window than
in the original.
Thomas Hood wrote:
>
> Please forgive me if I overlooked the message that
> already said this, but ...
>
> James Sutherland wrote that "There are valid uses for
> X only directories (i.e. users are not allowed to list
> the contents, only to access them directly by name).
> R-only directories make little sense". Then there
> followed a long discussion about the utility of "--x"
> directories. (I agree that they aren't a very good
> idea, since an explorable directory can be "listed" by
> trial and error on the filenames within it.)
Finding filenames by trial and error is hopeless.
It is _much_ easier to find the root
password by trial and error and then change the permissions
and list in the normal way.
There is only one root password to guess, but you think
having to guess _every_ filename is insecure?
A x-only directory is much safer than user security
will ever be - you effectively have a password per file.
>
> However, a decent reason for having separate r and x
> is that "r--" directories _do_ make sense. When a
> directory is "r--", its contents can be _listed_ but the
> directory cannot be browsed. Observe: // Thomas Hood
But is that useful?
Sure, I can list filenames. I can't get at filesize
or permissions. I can't open the files. How
is that useful? Of course locking people
out is useful, but why should they need to read
the filenames?
Helge Hafting
On Wed, Nov 21, 2001 at 11:34:07AM +0100, Helge Hafting wrote:
> Thomas Hood wrote:
> > However, a decent reason for having separate r and x
> > is that "r--" directories _do_ make sense. When a
> > directory is "r--", its contents can be _listed_ but the
> > directory cannot be browsed. Observe: // Thomas Hood
>
> But is that useful?
> Sure, I can list filenames. I can't get at filesize
> or permissions. I can't open the files. How
> is that useful? Of course locking people
> out is useful, but why should they need to read
> the filenames?
>
To taunt them? ;)