Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

execute-only permission

23 views
Skip to first unread message

mc

unread,
Sep 27, 2012, 4:52:23 AM9/27/12
to
Hi all,

I need to let "other people" access a single file in read-only mode.

I need to set the permission of a directories branch in order to avoid
the listing of the contens of any directory.

What I did is

find my_base_directory -type d -exec chown o-r+x {} \;

Is worke, but is it the proper way to do it?

Thanks for any advice.

Mc.

Bill Marcum

unread,
Sep 27, 2012, 9:29:08 AM9/27/12
to
I assume you meant chmod instead of chown. Your find command sets the
permission for other users to be the same for every directory in
my_base_directory, so they might be able to read other files if they can
guess the names.

Andy Walker

unread,
Sep 27, 2012, 12:28:52 PM9/27/12
to
On 27/09/12 09:52, mc wrote:
> I need to let "other people" access a single file in read-only mode.
> I need to set the permission of a directories branch in order to avoid
> the listing of the contens of any directory.

Something to consider is to have a "shares" directory,
specifically for this purpose [so it can be protected as much
or as little as you like] containing hard links to any files
you want to make available: "ln my/project/file $HOME/shares".
Then you just tell people to look in your "shares" directory.

Pro: There is no need to allow any access at all to the project
area, and indeed the project can be moved or rearranged without
having to tell anyone. There is no clue in the linkage as to
where the [rest of] the project is.
Con: Hard links have to be on the same filesystem. Some editing
and back-up tools and similar are quite cavalier about whether
edits are applied to the original file or to a copy [which means
that the linkage is lost and you have to re-instate it]. If
you have several or many "single files", then you have to be
careful about name collisions.

Symbolic links ["ln -s ..."] could be used instead, with somewhat
different pros and cons.

--
Andy Walker,
Nottingham.

mc

unread,
Sep 28, 2012, 3:29:30 AM9/28/12
to
You are right: in fact I tried using links, but (I didn't told it in my
post) these files are on shared NFS!

In practice, what I needed was to make accessible a file from

/shared/devel/bla/bla/bla/file

to

/shared/projects/

And both these branches are accessible using different groups

My solution was make accessible /shared/devel in read-only to "others"
avoiding the listing of files and set up a link inside /shared/project/
pointing to /shared/devel/bla/bla/bla/file

Thanks both for your help.

Mc.


PS: sorry for my goofy English :)

Thomas 'PointedEars' Lahn

unread,
Sep 28, 2012, 8:55:17 AM9/28/12
to
I do not know NFS well (I know more about CIFS), but isn't there an NFS
configuration where you can define who can and cannot access the files in
addition to file permission (there is for Samba)? That might be the cleaner
solution here.

--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

Ivan Shmakov

unread,
Sep 28, 2012, 10:58:59 AM9/28/12
to
>>>>> Andy Walker <ne...@cuboid.co.uk> writes:
>>>>> On 27/09/12 09:52, mc wrote:

>> I need to let "other people" access a single file in read-only mode.
>> I need to set the permission of a directories branch in order to
>> avoid the listing of the contens of any directory.

> Something to consider is to have a "shares" directory, specifically
> for this purpose [so it can be protected as much or as little as you
> like] containing hard links to any files you want to make available:
> "ln my/project/file $HOME/shares". Then you just tell people to look
> in your "shares" directory.

Seconded.

Indeed, I've advocated having a separate /home/public/users/
hierarchy for the users' "public" directories [1], and even
posted a few scripts (e. g., [2]) which make use of it.

[1] news:86wrcyjn...@gray.siamics.net
news:hEwSe-...@gated-at.bofh.it
http://groups.google.com/group/linux.debian.user/msg/575010544c818e27
[2] news:864npwg...@gray.siamics.net
http://ftp.funet.fi/index/archive/alt.sources/2716.gz

[...]

> Some editing and back-up tools and similar are quite cavalier about
> whether edits are applied to the original file or to a copy [which
> means that the linkage is lost and you have to re-instate it].

Usually, I'd prefer that the "public" revision of the file
remains the same as long as I don't replace it explicitly
myself. Which means that this "unlink-then-write" behavior of
the text editors is actually exactly what I want.

[...]

--
FSF associate member #7257
0 new messages