x bit for dirs: misfeature?

x bit for dirs: misfeature?

[vda]

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

Re: x bit for dirs: misfeature?

[James A Sutherland]

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.

Re: x bit for dirs: misfeature?

[vda]

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 :)

Re: x bit for dirs: misfeature?

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 220 bytes --]

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.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: x bit for dirs: misfeature?

[Richard B. Johnson]

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.

Re: x bit for dirs: misfeature?

[James A Sutherland]

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.

Re: x bit for dirs: misfeature?

[Kai Henningsen]

jas88@cam.ac.uk (James A Sutherland)  wrote on 19.11.01 in <E165qq7-0003QD-00@mauve.csi.cam.ac.uk>:

> [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

Re: x bit for dirs: misfeature?

[vda]

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

Re: x bit for dirs: misfeature?

[Horst von Brand]

vda <vda@port.imtp.ilyichevsk.odessa.ua> 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

Re: x bit for dirs: misfeature?

[James A Sutherland]

On Monday 19 November 2001 4:44 pm, Horst von Brand wrote:
> vda <vda@port.imtp.ilyichevsk.odessa.ua> 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.

Re: x bit for dirs: misfeature?

[vda]

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

Re: x bit for dirs: misfeature?

[James A Sutherland]

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.

Re: x bit for dirs: misfeature?

[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 jas88@cam.ac.uk
 rejects my direct emails:
   ----- Transcript of session follows -----
... while talking to navy.csi.cam.ac.uk.:
>>> RCPT To:<jas88@cam.ac.uk>
<<< 550 mail from 195.66.192.167 rejected: administrative prohibition (host 
is blacklisted)
550 5.1.1 <jas88@cam.ac.uk>... User unknown  ]
--
vda

Re: x bit for dirs: misfeature?

[Flavio Stanchina]

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/

Re: x bit for dirs: misfeature?

[vda]

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

Re: x bit for dirs: misfeature?

[Horst von Brand]

vda <vda@port.imtp.ilyichevsk.odessa.ua> 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

Re: x bit for dirs: misfeature?

[Anton Altaparmakov]

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/

Re: x bit for dirs: misfeature?

[Alexander Viro]

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.

Re: x bit for dirs: misfeature?

[Anton Altaparmakov]

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/

Re: x bit for dirs: misfeature?

[Mike Castle]

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      dalgoda@ix.netcom.com      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

Re: x bit for dirs: misfeature?

[Alexander Viro]

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.

Re: x bit for dirs: misfeature?

[vda]

On Monday 19 November 2001 18:14, Horst von Brand wrote:
> vda <vda@port.imtp.ilyichevsk.odessa.ua> 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

Re: x bit for dirs: misfeature?

[Jesse Pollard]

vda <vda@port.imtp.ilyichevsk.odessa.ua>
> 
> 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: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: x bit for dirs: misfeature?

[David Ford]

>
>
>>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

Re: x bit for dirs: misfeature?

[Pascal Schmidt]

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

-<[ pharao90@tzi.de, netmail 2:241/215.72, home http://cobol.cjb.net/) ]>-

Re: x bit for dirs: misfeature?

[J Sloan]

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

Re: x bit for dirs: misfeature?

[Alexander Viro]

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)

Re: x bit for dirs: misfeature?

[vda]

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

Re: x bit for dirs: misfeature?

[Shaya Potter]

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.

Re: x bit for dirs: misfeature?

[Alexander Viro]

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.

Re: x bit for dirs: misfeature?

[Mathijs Mohlmann]

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

Re: x bit for dirs: misfeature?

[Gerhard Mack]

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

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: x bit for dirs: misfeature?

[Horst von Brand]

vda <vda@port.imtp.ilyichevsk.odessa.ua> 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

Re: x bit for dirs: misfeature?

[Lionel Bouton]

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.

RE: x bit for dirs: misfeature?

[Mathijs Mohlmann]

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

Re: x bit for dirs: misfeature?

[vda]

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

Re: x bit for dirs: misfeature?

[Albert D. Cahalan]

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.

Re: x bit for dirs: misfeature?

[Thomas Hood]

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

Re: x bit for dirs: misfeature?

[Helge Hafting]

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

Re: x bit for dirs: misfeature?

[Mike Fedyk]

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? ;)