FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Red Hat Linux

 
 
LinkBack Thread Tools
 
Old 11-18-2011, 04:37 AM
kavya
 
Default Permission inheritance problem

*Hi all*,

Am working with file permission I have a query,

usually on /mnt normal users will not be having permission to write so I
gave permission such as
#chmod 766 /mnt
#chmod go+t /mnt I have enabled a sticky bit on /mnt for group and
others, as sticky bit is set, even the files and folders under /mnt can not
be deleted by others even if they have complete permissions and no sticky
bit is set for files under /mnt, is there any option to allow users to
delete only particular files ?????


Thanks,

Kavya
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-18-2011, 06:28 AM
"Mertens, Bram"
 
Default Permission inheritance problem

>


Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek
VAT BE 0406.024.281, RPR Mechelen, ING 310-0092504-52, IBAN : BE64 3100 0925 0452, SWIFT : BBRUBEBB

-----Original Message-----
> From: redhat-list-bounces@redhat.com [mailto:redhat-list-
> bounces@redhat.com] On Behalf Of kavya
> Sent: vrijdag 18 november 2011 6:38
> To: General Red Hat Linux discussion list
> Subject: Permission inheritance problem
>
> *Hi all*,
>
> Am working with file permission I have a query,
>
> usually on /mnt normal users will not be having permission to write so I
> gave permission such as
> #chmod 766 /mnt
> #chmod go+t /mnt I have enabled a sticky bit on /mnt for group and
> others, as sticky bit is set, even the files and folders under /mnt can not
> be deleted by others even if they have complete permissions and no sticky
> bit is set for files under /mnt, is there any option to allow users to
> delete only particular files ?????

What is it you are trying to achieve? Are you trying to use /mnt as a regular directory? Or using /mnt as it is designed, i.e. as a mount point for a remote file system?

If you are mounting a remote filesystem changing the permissions on /mnt won't have the desired effect.

How to grant permissions on a remote file system will depend on the type of that file system, NFS, samba, as well as the remote file system NTFS, ext2,3,4, XFS, etc..

Check man mount for options to set things like UID, GID, file modes etc. depending on which type of mount you are using.

Regards

Bram

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-18-2011, 07:35 AM
Cameron Simpson
 
Default Permission inheritance problem

On 18Nov2011 11:07, kavya <kavya.g4@gmail.com> wrote:
| Am working with file permission I have a query,
|
| usually on /mnt normal users will not be having permission to write so I
| gave permission such as
| #chmod 766 /mnt

Surely you want 777 here? A directory with no 'x' permission is not
searchable; 'r' only lets someone see the names of the things in the
directory, 'x' (search) lets them access it. So with a directory you
almost always want to grant 'x' if you grant any access. You don't need
to give 'r', but it is usual. So 'r-x' and '--x' are sensible, 'r--' is
usually not sensible.

| #chmod go+t /mnt

You just want "+t" here. There is no such thing as "sticky bit for
group" or "sticky bit for other". There is only one bit.

| I have enabled a sticky bit on /mnt for group and
| others, as sticky bit is set, even the files and folders under /mnt can not
| be deleted by others even if they have complete permissions and no sticky
| bit is set for files under /mnt,

Yes.

| is there any option to allow users to
| delete only particular files ?????

No. The permissions on /mnt apply to the directory as a whole,
not on a per-name basis.

If you want per-name control the best you can do is make subdirectories
and grant different accesses to those. Which is what home directories
effectively are, if you would like a similar arrangement.

Cheers,
--
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

My opinions are borrowed from someone who no longer needs them.
-- KatmanDu@uga.cc.uga.edu

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-18-2011, 09:04 AM
kavya
 
Default Permission inheritance problem

so if i set a sticky bit it applies for owner also????

On Fri, Nov 18, 2011 at 2:05 PM, Cameron Simpson <cs@zip.com.au> wrote:

> On 18Nov2011 11:07, kavya <kavya.g4@gmail.com> wrote:
> | Am working with file permission I have a query,
> |
> | usually on /mnt normal users will not be having permission to write so I
> | gave permission such as
> | #chmod 766 /mnt
>
> Surely you want 777 here? A directory with no 'x' permission is not
> searchable; 'r' only lets someone see the names of the things in the
> directory, 'x' (search) lets them access it. So with a directory you
> almost always want to grant 'x' if you grant any access. You don't need
> to give 'r', but it is usual. So 'r-x' and '--x' are sensible, 'r--' is
> usually not sensible.
>
> | #chmod go+t /mnt
>
> You just want "+t" here. There is no such thing as "sticky bit for
> group" or "sticky bit for other". There is only one bit.
>
> | I have enabled a sticky bit on /mnt for group and
> | others, as sticky bit is set, even the files and folders under /mnt can
> not
> | be deleted by others even if they have complete permissions and no sticky
> | bit is set for files under /mnt,
>
> Yes.
>
> | is there any option to allow users to
> | delete only particular files ?????
>
> No. The permissions on /mnt apply to the directory as a whole,
> not on a per-name basis.
>
> If you want per-name control the best you can do is make subdirectories
> and grant different accesses to those. Which is what home directories
> effectively are, if you would like a similar arrangement.
>
> Cheers,
> --
> Cameron Simpson <cs@zip.com.au> DoD#743
> http://www.cskk.ezoshosting.com/cs/
>
> My opinions are borrowed from someone who no longer needs them.
> -- KatmanDu@uga.cc.uga.edu
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>



--

Thanks and Regards

Kavya.N(Koramangala)
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-18-2011, 08:31 PM
Cameron Simpson
 
Default Permission inheritance problem

On 18Nov2011 15:34, kavya <kavya.g4@gmail.com> wrote:
| so if i set a sticky bit it applies for owner also????

1: Please DO NOT top post. Replies belong _below_ the quoted text, which
should be trimmed to provide context and not clutter.

2: No. Reading "man chmod" (you _have_ done this already, yes?):

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

The manual is your friend.

Cheers,
--
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

I have an inferiority complex, but it isn't a very good one.
- Bill Garrett <garrett@cs.unc.edu>

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-19-2011, 06:10 PM
Radomir Żółtowski
 
Default Permission inheritance problem

> is there any option to allow users to
> delete only particular files ?????

If you are looking for a functionality beyond standard permissions, read about mounting options and ACLs here:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-acls.html

R.

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-21-2011, 12:24 AM
Sanjay Chakraborty
 
Default Permission inheritance problem

Sticky bit user for collaboration directory. and how it works in short:

suppose you create a group dev and create a directory /limit and that
is owned by dev group.

Now a user joe he is in dev group as secondary group. He wants to
modify a file in that directory but he will get 'permission deny' even
the directory is owned by dev group and it is 770.

Solution: apply stcky bit in that directory .. chmod 2770 /limit

Now joe can read write and execute files in /limit directory.

Does it helped ?


On Fri, Nov 18, 2011 at 5:04 AM, kavya <kavya.g4@gmail.com> wrote:
> so if i set a sticky bit it applies for owner also????
>
> On Fri, Nov 18, 2011 at 2:05 PM, Cameron Simpson <cs@zip.com.au> wrote:
>
>> On 18Nov2011 11:07, kavya <kavya.g4@gmail.com> wrote:
>> | * * * * * Am working with file permission I have a query,
>> |
>> | usually on /mnt normal users will not be having permission to write so I
>> | gave permission such as
>> | #chmod 766 /mnt
>>
>> Surely you want 777 here? A directory with no 'x' permission is not
>> searchable; 'r' only lets someone see the names of the things in the
>> directory, 'x' (search) lets them access it. So with a directory you
>> almost always want to grant 'x' if you grant any access. You don't need
>> to give 'r', but it is usual. So 'r-x' and '--x' are sensible, 'r--' is
>> usually not sensible.
>>
>> | #chmod go+t /mnt
>>
>> You just want "+t" here. There is no such thing as "sticky bit for
>> group" or "sticky bit for other". There is only one bit.
>>
>> | I have enabled a sticky bit on /mnt *for group and
>> | others, as sticky bit is set, even the files and folders under /mnt can
>> not
>> | be deleted by others even if they have complete permissions and no sticky
>> | bit is set for files under /mnt,
>>
>> Yes.
>>
>> | is there any option to allow users to
>> | delete only particular files ?????
>>
>> No. The permissions on /mnt apply to the directory as a whole,
>> not on a per-name basis.
>>
>> If you want per-name control the best you can do is make subdirectories
>> and grant different accesses to those. Which is what home directories
>> effectively are, if you would like a similar arrangement.
>>
>> Cheers,
>> --
>> Cameron Simpson <cs@zip.com.au> DoD#743
>> http://www.cskk.ezoshosting.com/cs/
>>
>> My opinions are borrowed from someone who no longer needs them.
>> * * * *-- KatmanDu@uga.cc.uga.edu
>>
>> --
>> redhat-list mailing list
>> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/redhat-list
>>
>
>
>
> --
>
> Thanks and Regards
>
> * * * * Kavya.N(Koramangala)
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>



--
Regards.
Sanjay Chakraborty

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-22-2011, 04:35 PM
"white.heron white"
 
Default Permission inheritance problem

Dear All,

Fya.

chmod*Examples
Let’s change some of the permissions as we discussed a couple of pages ago. Here’s the way our files are now:
-rwxr-xr-x joe acctg archive.sh
-rw-rw-r-- joe acctg orgchart.gif
-rw-rw-r-- joe acctg personnel.txt
-rw-r--r-- joe acctg publicity.html
drwxrwxr-x joe acctg sales
-rw-r----- joe acctg topsecret.inf
-rwxr-xr-x joe acctg wordmatic
First, let’s prevent outsiders from executing*archive.sh
Before: -rwxr-xr-x**archive.sh
Command: chmod o=r archive.sh
After: -rwxr-xr--**archive.sh
Take away all permissions for the group for*topsecret.inf*We do this by leaving the permissions part of the command empty.
Before: -rw-r-----**topsecret.inf
Command: chmod g= topsecret.inf
After: -rw-------**topsecret.inf
Open up*publicity.html*for reading and writing by anyone.
Before: -rw-r--r--**publicity.html
Command: chmod og=rw publicity.html
After: -rw-rw-rw-**publicity.html





*
Regards,


MOHAMMAD ADLI BIN MT TAJUDIN
A8-2-7, DESA PANDAN APARTMENTS,
OFF JALAN KG. PANDAN,
55100 KUALA LUMPUR,
WEST MALAYSIA.


H/p number: *(017) 362 3661
Email: white.heron@yahoo.com


________________________________
From: Sanjay Chakraborty <sanjaychakrab@gmail.com>
To: General Red Hat Linux discussion list <redhat-list@redhat.com>
Sent: Monday, November 21, 2011 9:24 AM
Subject: Re: Permission inheritance problem

Sticky bit user for collaboration directory. and how it works in short:

suppose you create a group dev and create a directory /limit and that
is owned by dev group.

Now a user joe he is in dev group as secondary group. He wants to
modify a file in that directory but he will get 'permission deny' even
the directory is owned by dev group and it is 770.

Solution: apply stcky bit in that directory .. chmod 2770 /limit

Now joe can read write and execute files in /limit* directory.

Does it helped ?


On Fri, Nov 18, 2011 at 5:04 AM, kavya <kavya.g4@gmail.com> wrote:
> so if i set a sticky bit it applies for owner also????
>
> On Fri, Nov 18, 2011 at 2:05 PM, Cameron Simpson <cs@zip.com.au> wrote:
>
>> On 18Nov2011 11:07, kavya <kavya.g4@gmail.com> wrote:
>> | * * * * * Am working with file permission I have a query,
>> |
>> | usually on /mnt normal users will not be having permission to write so I
>> | gave permission such as
>> | #chmod 766 /mnt
>>
>> Surely you want 777 here? A directory with no 'x' permission is not
>> searchable; 'r' only lets someone see the names of the things in the
>> directory, 'x' (search) lets them access it. So with a directory you
>> almost always want to grant 'x' if you grant any access. You don't need
>> to give 'r', but it is usual. So 'r-x' and '--x' are sensible, 'r--' is
>> usually not sensible.
>>
>> | #chmod go+t /mnt
>>
>> You just want "+t" here. There is no such thing as "sticky bit for
>> group" or "sticky bit for other". There is only one bit.
>>
>> | I have enabled a sticky bit on /mnt *for group and
>> | others, as sticky bit is set, even the files and folders under /mnt can
>> not
>> | be deleted by others even if they have complete permissions and no sticky
>> | bit is set for files under /mnt,
>>
>> Yes.
>>
>> | is there any option to allow users to
>> | delete only particular files ?????
>>
>> No. The permissions on /mnt apply to the directory as a whole,
>> not on a per-name basis.
>>
>> If you want per-name control the best you can do is make subdirectories
>> and grant different accesses to those. Which is what home directories
>> effectively are, if you would like a similar arrangement.
>>
>> Cheers,
>> --
>> Cameron Simpson <cs@zip.com.au> DoD#743
>> http://www.cskk.ezoshosting.com/cs/
>>
>> My opinions are borrowed from someone who no longer needs them.
>> * * * *-- KatmanDu@uga.cc.uga.edu
>>
>> --
>> redhat-list mailing list
>> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/redhat-list
>>
>
>
>
> --
>
> Thanks and Regards
>
> * * * * Kavya.N(Koramangala)
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>



--
Regards.
Sanjay Chakraborty

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-22-2011, 09:53 PM
Cameron Simpson
 
Default Permission inheritance problem

On 22Nov2011 09:35, white.heron white <white.heron@yahoo.com> wrote:
| Dear All,
| Fya.
|
| chmod*Examples
| Let’s change some of the permissions as we discussed a couple of pages ago. Here’s the way our files are now:
[...]

Hey lazy idiot.

If you are going to cut/paste someone else's work instead of thinking, at
least have the basic integrity to CREDIT THE SOURCE!

Just ripping the text from:

http://catcode.com/teachmod/chmod_cmd2.html

without attribution or context is extremely discourteous.

That is does not answer the original question just adds insult to the
offensiveness.

You are a lazy idiot. Please don't post unless you have something to
contribute and the honesty to reference your sources.
--
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 11-23-2011, 09:25 AM
Amit Awasthi
 
Default Permission inheritance problem

You can give 777 instead of 766...it should work..
Thanks,
Amit

On Fri, Nov 18, 2011 at 11:07 AM, kavya <kavya.g4@gmail.com> wrote:

> *Hi all*,
>
> Am working with file permission I have a query,
>
> usually on /mnt normal users will not be having permission to write so I
> gave permission such as
> #chmod 766 /mnt
> #chmod go+t /mnt I have enabled a sticky bit on /mnt for group and
> others, as sticky bit is set, even the files and folders under /mnt can not
> be deleted by others even if they have complete permissions and no sticky
> bit is set for files under /mnt, is there any option to allow users to
> delete only particular files ?????
>
>
> Thanks,
>
> Kavya
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>



--
Amit Awasthi | IT Department | SmartbuzzInc | Ph: 978-068-1431 |
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 

Thread Tools




All times are GMT. The time now is 07:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org