dir permissions in linux: does a "w" without an "x" mean anything useful?
Rahul
(1) Is there any situation where one might want to give a write permision
but deny a read permission (file or dir)? Or is this combination always
meaningless (as it naiively seems to me)
(2)For directories specificlly:
I tried giving my group w permissions on a dir. What exactly does the w
allow them to do? I thought it was supposed to allow them to delete files
in that dir but it does not (unless combined with an x).
drwxrw---- dir
-rw-r----- dir/file
Neither can they delete that dir itself.
In fact although there's read permissions on both dir and dir/file they
cannot read that file either. I thought even without the x permission on a
dir a user was supposed to be able to read a file if he knew the exact
name.
To rephrase: "What previlage does a "w" on a dir yield by itself? Or does
it always have to be combined with an "x"?"
I've always used chmod g+rx on dirs but just got me thinking today.
--
Rahul
Robert Heller
>
> Questions about permissions on Linux:
>
> (1) Is there any situation where one might want to give a write permision
> but deny a read permission (file or dir)? Or is this combination always
> meaningless (as it naiively seems to me)
w without r simply allows writing, but not reading. From the specific
user's POV, it is like a black hole: files can be writen to, but not read.
>
> (2)For directories specificlly:
>
> I tried giving my group w permissions on a dir. What exactly does the w
> allow them to do? I thought it was supposed to allow them to delete files
> in that dir but it does not (unless combined with an x).
>
> drwxrw---- dir
> -rw-r----- dir/file
>
> Neither can they delete that dir itself.
>
> In fact although there's read permissions on both dir and dir/file they
> cannot read that file either. I thought even without the x permission on a
> dir a user was supposed to be able to read a file if he knew the exact
> name.
Yes. He does need read access through all directories in the path.
>
> To rephrase: "What previlage does a "w" on a dir yield by itself? Or does
> it always have to be combined with an "x"?"
"w" on a dir yields file delete and create access (eg the ablity to
change the directory file itself, by adding and deleting entries).
>
> I've always used chmod g+rx on dirs but just got me thinking today.
'x' on a directory allows for a directory listing (or anything similar,
like wildcard (or shell) expansion). Without the 'x', the given user
cannot see what else is in the directory. A 'w' (and/or 'r') on a
directory *without* a 'x' restricts the class of users (group or other)
to only delete (and/or read) files, so long as the full pathname is
(blindly) known to that class of users.
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
hel...@deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
wisdomkiller & pain
> Questions about permissions on Linux:
>
....
Best you can do is to try it out with a testdir and a (set of) testfile(s).
You should notice, "execute" on a directory means "traverse permission".
Ownership or group r/w permissions for a directory include files therein.
There are sgid and sticky bits as well, for fine-tuning.
Just a little googling will lead you to sites like
http://www.dartmouth.edu/~rc/help/faq/permissions.html
and many others.
Nathan Keel
The x is executable. The w is write. The r is read. d is directory -
for file. For no file listings in a directory for another user, set
the directory to 0711 (or 0701) instead of 0760 (which you have now).
Otherwise only the user that owns the directory can view/access or run
the file.
Jakub Fišer
> At Wed, 22 Apr 2009 15:16:12 +0000 (UTC) Rahul <nos...@nospam.invalid> wrote:
>
> >
> > Questions about permissions on Linux:
> >
> > (1) Is there any situation where one might want to give a write permision
> > but deny a read permission (file or dir)? Or is this combination always
> > meaningless (as it naiively seems to me)
>
> w without r simply allows writing, but not reading. From the specific
> user's POV, it is like a black hole: files can be writen to, but not read.
WOM (Write-only media - that includes files, that cannot be read from) can be
used for example for storing private keys - noone really need to know the key,
just a secure mechanism to use the key - like smardcards or tokens. Same can be
done for a file if you want to (i.e. readable only by encryption software, but
writable with key generator)... Just a wild idea :)
>
> >
> > (2)For directories specificlly:
> >
> > I tried giving my group w permissions on a dir. What exactly does the w
> > allow them to do? I thought it was supposed to allow them to delete files
> > in that dir but it does not (unless combined with an x).
> >
> > drwxrw---- dir
> > -rw-r----- dir/file
> >
> > Neither can they delete that dir itself.
> >
> > In fact although there's read permissions on both dir and dir/file they
> > cannot read that file either. I thought even without the x permission on a
> > dir a user was supposed to be able to read a file if he knew the exact
> > name.
>
> Yes. He does need read access through all directories in the path.
Nope, read permission on a directory is not needed when accessing its
files, "execute" permission is. see down:
>
> >
> > To rephrase: "What previlage does a "w" on a dir yield by itself? Or does
> > it always have to be combined with an "x"?"
>
> "w" on a dir yields file delete and create access (eg the ablity to
> change the directory file itself, by adding and deleting entries).
this part is true - an entry can be whatever can reside in filesystem (file,
directory, symlink, socket, pipe...) - BUT:
> >
> > I've always used chmod g+rx on dirs but just got me thinking today.
>
> 'x' on a directory allows for a directory listing (or anything similar,
> like wildcard (or shell) expansion). Without the 'x', the given user
> cannot see what else is in the directory. A 'w' (and/or 'r') on a
> directory *without* a 'x' restricts the class of users (group or other)
> to only delete (and/or read) files, so long as the full pathname is
> (blindly) known to that class of users.
this paragraph is a mixup. the -x- permission allows one to ACCESS the
directory (i.e. "chdir to it" and interact with its entries) while the -r-
allows one to see its content (i.e. "ls it"). The -w- lets user modify the
directory content (i.e. adding and removing entries). Now it gets interesting:)
The -w- lets you change the content BUT the content is in fact a bunch of
entries which cannot be interacted without -x- permission. Hence an -w- without
-x- doesn't make much sense* while an -x- without -w- or -r- makes perfect
sense.
(*) while you cannot interact with entries in the directory, you can still
interact with the directory itself - like changing its modification time or
group - for that you don't need the -x- permission.
If you want to acces a file in the filesystem, all directories in path must
have at least -x- permission for you.
There is however one problem with -w-: anyone who has the -w- permission can
delete any file in the directory even if the file is inaccesible to him in
any way, since he is not interacting with the file itself but just with an
entry in a directory.
To prevent this we have yet another "permission" - sticky. On files it has no
effect (it has something to do with keeping binaries in memory but now its
ignored).On DIRECTORIES however it makes you unable to delete entries that you
do not own.
hope it makes better sense to you now :)
cheers,
-miky
--
Jakub Fišer AKA m...@MikyMaus.org
ICQ: I don't see kyou - http://icq.xmpp.cz/
JID: mr.Mi...@jabber.cz
Vyhýbejte se, prosím, přílohám typu Word nebo PowerPoint:
http://www.gnu.org/philosophy/no-word-attachments.cs.html
Please avoid sending me Word, PowerPoint, etc. attachments:
http://www.gnu.org/philosophy/no-word-attachments.html
Maxwell Lol
> Questions about permissions on Linux:
>
> (1) Is there any situation where one might want to give a write permision
> but deny a read permission (file or dir)? Or is this combination always
> meaningless (as it naiively seems to me)
You can use it to allow people to write files into a queue directory,
but deny others the ability to read what others submit.
>
> (2)For directories specificlly:
>
> I tried giving my group w permissions on a dir. What exactly does the w
> allow them to do? I thought it was supposed to allow them to delete files
> in that dir but it does not (unless combined with an x).
On a directory -
W allows people to create and rename files. You might also need r to rename.
x allows people to see the names of the files in a directory.
It means "search."
If you KNOW the name, you can read and write files in a directory
without x.
Keith Keller
>
> this paragraph is a mixup. the -x- permission allows one to ACCESS the
> directory (i.e. "chdir to it" and interact with its entries) while the -r-
> allows one to see its content (i.e. "ls it"). The -w- lets user modify the
> directory content (i.e. adding and removing entries). Now it gets interesting:)
> The -w- lets you change the content BUT the content is in fact a bunch of
> entries which cannot be interacted without -x- permission. Hence an -w- without
> -x- doesn't make much sense* while an -x- without -w- or -r- makes perfect
> sense.
[snip]
> There is however one problem with -w-: anyone who has the -w- permission can
> delete any file in the directory even if the file is inaccesible to him in
> any way, since he is not interacting with the file itself but just with an
> entry in a directory.
As you noted, you need at least +wx permission on a directory to delete
or rename a file (though it's still true that the individual file
permissions are irrelevant to deleting or moving).
> To prevent this we have yet another "permission" - sticky. On files it has no
> effect (it has something to do with keeping binaries in memory but now its
> ignored).On DIRECTORIES however it makes you unable to delete entries that you
> do not own.
And to set the sticky bit do
chmod +t dirname/
-t removes the sticky bit.
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Robert Riches
Slight attempt at correction of the last sentence:
If you know the name, you can read and write the files in a
directory without 'r'. Basically, 'r' lets you learn the names,
while 'x' lets you get to the files once you know the names.
--
Robert Riches
spamt...@verizon.net
(Yes, that is one of my email addresses.)
Jakub Fišer
yep, true. here's the proof:
[miky@ghoulie x]$ ls -l
total 0
drwxrwxrwx 2 miky users 8 2009-04-23 11:09 directory
[miky@ghoulie x]$ ls -l directory/
total 4
-rw-r--r-- 1 miky users 29 2009-04-23 11:10 entry
[miky@ghoulie x]$ cat directory/entry
this is content of the entry
[miky@ghoulie x]$ chmod a-x directory/
[miky@ghoulie x]$ ls -l
total 0
drw-rw-rw- 2 miky users 8 2009-04-23 11:09 directory
[miky@ghoulie x]$ cat directory/entry
cat: directory/entry: Permission denied
[miky@ghoulie x]$ echo directory/*
directory/entry
[miky@ghoulie x]$ chmod a-r directory/
[miky@ghoulie x]$ echo directory/*
directory/*
(I use echo since ls produces some not quite relevant error messages)
-m.
Rahul
news:20090422231212.727d46a4@ghoulie:
> To prevent this we have yet another "permission" - sticky. On files it
> has no effect (it has something to do with keeping binaries in memory
> but now its ignored).On DIRECTORIES however it makes you unable to
> delete entries that you do not own.
>
>
> hope it makes better sense to you now :)
>
Thanks guys! This helps a lot. I was already pretty comfy with rwx on files
but dirs were always somewhat of a mysterious beast. And these were the
sort of tricky combinations that the sites out there do not explain.
A follow up question:
There is no way in Linux of making a sub-folder deep down visible without
having all its parent dirs visible (seacrhable) too is there?
i.e. I need a +rx on all parent dirs.
So I cannot publish "public" from /foo/bar/secret/public without yielding
at least listing rights on /foo/bar/secret?
Or is there a trick around this? I suspect there is, because otherwise this
would be a somewhat arbitrary requirement that stems more from
implimentation than user-needs and that is so unlike most things linuxey!
:)
--
Rahul
Unruh
>Jakub =?UTF-8?B?RmnFoWVy?= <m...@MikyMaus.org> wrote in
>news:20090422231212.727d46a4@ghoulie:
>> To prevent this we have yet another "permission" - sticky. On files it
>> has no effect (it has something to do with keeping binaries in memory
>> but now its ignored).On DIRECTORIES however it makes you unable to
>> delete entries that you do not own.
>>
>>
>> hope it makes better sense to you now :)
>>
>Thanks guys! This helps a lot. I was already pretty comfy with rwx on files
>but dirs were always somewhat of a mysterious beast. And these were the
>sort of tricky combinations that the sites out there do not explain.
man chmod
RESTRICTED DELETION FLAG OR STICKY BIT
The restricted deletion flag or sticky bit is a single bit, whose
interpretation depends on the file type. For directories, it prevents
unprivileged users from removing or renaming a file in the directory
unless they own the file or the directory; this is called the
restricted deletion flag for the directory, and is commonly found on
world-writable directories like /tmp. For regular files on some older
systems, the bit saves the program's text image on the swap device so
it will load more quickly when run; this is called the sticky bit.
>A follow up question:
>There is no way in Linux of making a sub-folder deep down visible without
>having all its parent dirs visible (seacrhable) too is there?
If you know where it is sure. The parent does not need to be readable to
be able to search it.
Thus if your directory is /my/deep/buried/directory. if my,deep, and buried
do not have r set, then doing
ls /my/deep/buried/directory
will list the files in that directory.
But ls /my/deep/buried
will show nothing (permission denied)
>i.e. I need a +rx on all parent dirs.
not if you do not want to read the parents
>So I cannot publish "public" from /foo/bar/secret/public without yielding
>at least listing rights on /foo/bar/secret?
see above. Exeriments are great. And much faster than asking.
Keith Keller
>
> There is no way in Linux of making a sub-folder deep down visible without
> having all its parent dirs visible (seacrhable) too is there?
>
> i.e. I need a +rx on all parent dirs.
You need +x on all parent dirs, but you only need +r on the last dir...
> So I cannot publish "public" from /foo/bar/secret/public without yielding
> at least listing rights on /foo/bar/secret?
...so you need +rx on public, but only +x on secret. Then users will
not be able to list secret (though they will still be able to cd to
secret, and if they know the name of a file will be able to work with it
if they have the correct file permissions.
> Or is there a trick around this? I suspect there is, because otherwise this
> would be a somewhat arbitrary requirement that stems more from
> implimentation than user-needs and that is so unlike most things linuxey!
I dunno if the above counts as a trick or not. :)
Robert Nichols
Rahul <nos...@nospam.invalid> wrote:
:Questions about permissions on Linux:
:
:(1) Is there any situation where one might want to give a write permision
:but deny a read permission (file or dir)? Or is this combination always
:meaningless (as it naiively seems to me)
Back in simpler, kinder times, it was common for a user's login TTY
device to have write-only permission for others, allowing other users to
send messages directly to the terminal but not to steal keyboard input.
Yes, there are huge security holes associated with that, but it was a
kinder, gentler world back then.
--
Bob Nichols AT comcast.net I am "RNichols42"
Rahul
news:Gq2Il.23744$Db2.9416@edtnps83:
>>i.e. I need a +rx on all parent dirs.
>
> not if you do not want to read the parents
>
>>So I cannot publish "public" from /foo/bar/secret/public without
>>yielding at least listing rights on /foo/bar/secret?
>
> see above. Exeriments are great. And much faster than asking.
>
>
I was experimenting with a file which has a +w but no r.
Is the "write" here restricted to "append" or "full overwrite" in a sense.
I could use echo to add stuff to the end of the file etc.
But let's say the original file had a line:
line2
Is it possible to, say, "write" text to the top of the file?
line1
line2
I ask, since vim interestingly, reports: "Warning: Changing a readonly
file"
In fact, this file is "write only". Funny.
--
Rahul
Harold Stevens
[Snip...]
> kinder, gentler world back then
Also nice to run X remote sessions "cleanly" over networks basically by
naively redefining the DISPLAY environment. I too miss those days.
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
I toss GoogleGroup posts from gitgo (http://improve-usenet.org).
Keith Keller
>
>
> Is the "write" here restricted to "append" or "full overwrite" in a sense.
> I could use echo to add stuff to the end of the file etc.
>
> But let's say the original file had a line:
>
> line2
>
> Is it possible to, say, "write" text to the top of the file?
>
> line1
> line2
What happened when you tried it?
(yes, write is "full overwrite": you could use echo to replace the file
completely if you wanted)
Jakub Fišer
So what you essentially ask about is whether write-only files are seekable..
That's very interesting question, I never thought of it that way...:) Anyone has
experience with this?
-m.
John Hasler
> So what you essentially ask about is whether write-only files are
> seekable..
They certainly should be seekable, but not to negative values.
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
Maxwell Lol
> There is no way in Linux of making a sub-folder deep down visible without
> having all its parent dirs visible (seacrhable) too is there?
>
> i.e. I need a +rx on all parent dirs.
You only need x on all but the bottom-most.
Maxwell Lol
> Is it possible to, say, "write" text to the top of the file?
>
> line1
> line2
>
> I ask, since vim interestingly, reports: "Warning: Changing a readonly
> file"
>
> In fact, this file is "write only". Funny.
You can create a new file that is a copy of that file.
Rahul
> So what you essentially ask about is whether write-only files are
> seekable.. That's very interesting question, I never thought of it
> that way...:) Anyone has experience with this?
>
>
Thanks Jakub. Exactly what I meant. Is there anything special about an
append rather than a prepend?
--
Rahul
Rahul
> You can create a new file that is a copy of that file.
>
cp level1/test ~/
cp: cannot open `level1/test' for reading: Permission denied
--
Rahul
Rahul
news:g047c6x...@goaway.wombat.san-francisco.ca.us:
> What happened when you tried it?
>
> (yes, write is "full overwrite": you could use echo to replace the file
> completely if you wanted)
>
>
I do not know how to try it!
Append with a "echo foo >> file" works.
Overwrite with a echo "bar > file" also works
But what Linux command can I use to prepend data to a file that I am not
supposed to be able to read?
--
Rahul
Keith Keller
>
> But what Linux command can I use to prepend data to a file that I am not
> supposed to be able to read?
Hmm, I guess that's not what you asked; I read "full overwrite" to mean
clobber the target file, not prepend.
I don't think you can prepend to a file using standard shell
redirection; you can either clobber or append. But that's a shell IO
issue; in theory if such an operator existed you could do it. But are
you asking just out of curiosity, or do you have a need for this
feature? If you think you need to prepend a write-only file, can you
describe exactly what your situation is?
Maxwell Lol
Oopss. Yes. Sorry. Lost track of the conditions.
Jules
> But what Linux command can I use to prepend data to a file that I am not
> supposed to be able to read?
I'm not sure that you can without doing some programming (e.g. using open
and lseek functions in C).
All the standard utilities seem to be designed to read input, modify it,
and write output somewhere else - and the user can then overwrite the
source data with the changed data if they need to after doing whatever
checks are appropriate for the environment. Makes sense, I think;
multiple scripts can process data without the need to worry about file /
record locking, data corruption, concurrency issues etc.
cheers
Jules
Rahul
> issue; in theory if such an operator existed you could do it. But are
> you asking just out of curiosity, or do you have a need for this
> feature? If you think you need to prepend a write-only file, can you
> describe exactly what your situation is?
>
>
Thank Kieth. Purely out of curiosity. After Unruh suggested I "experiment"
I got carried away I guess. :)
Often understanding how these limiting (and often unrealistic) cases work
seems to gain me tiny further insights into how Linux works.
--
Rahul
Rahul
news:pan.2009.04.24....@remove.this.gmail.com:
> I'm not sure that you can without doing some programming (e.g. using open
> and lseek functions in C).
>
So, if a file is "write only" does linux have checks that prevent the C-
program from seeking within the original-area that is supposed to be read-
hidden? How does that work?
--
Rahul
Jules
I'm guessing that "seeking" is neither reading or writing - it's just
changing a pointer to the 'current location' in a file and is therefore
considered harmless - if given a valid file handle, lseek probably just
works*, regardless of file permissions (but obviously to get a valid file
handle in the first place, the owner must have had permission to open the
file :-)
* I assume that permissions are only checked at file open time (whether
opened for reading, writing or both) - *not* on every access, as the
latter seems like a huge performance hit.
If I get a few minutes later (and if nobody else confirms or denies any
of the above) I might throw some quick test code together and see what
happens...
cheers
Jules
John Hasler
> So, if a file is "write only" does linux have checks that prevent the C-
> program from seeking within the original-area that is supposed to be
> read- hidden? How does that work?
If you do not have read permission on a file you cannot open it for
reading. It doesn't matter who wrote the program you are trying to do it
with: the open() will fail. You will be able to seek anywhere within the
file (and beyond the end of the file) but you will not be able to read.
And you will not, of course, be able to seek before the beginning of the
file in any case.
Keith Keller
>
> I got carried away I guess. :)
>
> Often understanding how these limiting (and often unrealistic) cases work
> seems to gain me tiny further insights into how Linux works.
Agreed! You never know when some stupid trick you learn from these
unrealistic cases will come in handy. (It also helps to know the bounds
of the system, since those are going to be places that exploits attempt
to, well, exploit.)
Robert Riches
>
> * I assume that permissions are only checked at file open time (whether
> opened for reading, writing or both) - *not* on every access, as the
> latter seems like a huge performance hit.
That assumption would be consistent with my study and
experience. A fair number of security issues with
application programs are caused by creating a readable
temporary file and then unlinking or changing permission on
the file. An attacker could open the file for read during
the brief period of vulnerability and then continue to read
from the file afterward.
Chris F.A. Johnson
There is no such thing as prepend. To prepend, one must create a
new file and move it into the place of the old, or copy the old and
build the prepended file there.
--
Chris F.A. Johnson, author | <http://cfaj.freeshell.org>
Shell Scripting Recipes: | My code in this post, if any,
A Problem-Solution Approach | is released under the
2005, Apress | GNU General Public Licence