Prev: where's udevinfo ?
Next: Confirming submission of bug report
From: AG on 17 Jul 2010 16:50
Hi

I have created another account for someone who will need to use my
computer for a while. However, when checking this, I found that my own
files are viewable from this second account.

How do I set the permissions so that the contents of my own /home/ag
account are not viewable from the new user account? For obvious
reasons, I want to be careful about the permissions I set so I don't
lock myself out. I think that it is chown 700 /home/ag -R but can
someone please confirm that this will do what I want before I screw
things up.

Many thanks

AG


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4C421257.1010707(a)gmail.com
From: Bob Proulx on 17 Jul 2010 17:20
AG wrote:
> I have created another account for someone who will need to use my
> computer for a while. However, when checking this, I found that my own
> files are viewable from this second account.

By default files in the home are readable but not writable.

> How do I set the permissions so that the contents of my own /home/ag
> account are not viewable from the new user account?

$ chmod o-rwx ~/

That is 'o' for 'other' minus read-write-execute permissions. You can
run that recursively if you like with 'chmod -R'.

> For obvious reasons, I want to be careful about the permissions I
> set so I don't lock myself out. I think that it is chown 700
> /home/ag -R but can someone please confirm that this will do what I
> want before I screw things up.

I commend you for asking. Using 'chown 700 /home/ag -R' would
probably fail but does something completely different on two counts.
One is that you want chmod not chown. 'chown 700' would try to change
the ownership to user number 700, but would probably fail since only
root can give away file ownership[1].

But then if you had actually used 'chmod 700' it would be bad because
that hard sets the execute bit on every file! You don't want that
either. Also you really have no reason to lock out your own group, it
is your own group after all, so leave off the group restriction. Read
up on UPG (user private groups) for more information.

Using the symbolic modes is the modern way (modern as in as of around
twenty years ago modern) and avoids the trap of hard setting all of
the bits. I think they are easier for people to understand too. If
you want to do it the old way with hard numbers then using 'find' is
the way to go. And if you have messed things up then some creative
find commands can repair things.

Bob

[1] http://www.gnu.org/software/coreutils/faq/#Why-can-only-root-chown-files_003f
From: AG on 18 Jul 2010 05:10
On 17/07/10 22:19, Bob Proulx wrote:
> AG wrote:
>
>> I have created another account for someone who will need to use my
>> computer for a while. However, when checking this, I found that my own
>> files are viewable from this second account.
>>
> By default files in the home are readable but not writable.
>
>
>> How do I set the permissions so that the contents of my own /home/ag
>> account are not viewable from the new user account?
>>
> $ chmod o-rwx ~/
>
> That is 'o' for 'other' minus read-write-execute permissions. You can
> run that recursively if you like with 'chmod -R'.
>
>
>> For obvious reasons, I want to be careful about the permissions I
>> set so I don't lock myself out. I think that it is chown 700
>> /home/ag -R but can someone please confirm that this will do what I
>> want before I screw things up.
>>
> I commend you for asking. Using 'chown 700 /home/ag -R' would
> probably fail but does something completely different on two counts.
> One is that you want chmod not chown. 'chown 700' would try to change
> the ownership to user number 700, but would probably fail since only
> root can give away file ownership[1].
>
> But then if you had actually used 'chmod 700' it would be bad because
> that hard sets the execute bit on every file! You don't want that
> either. Also you really have no reason to lock out your own group, it
> is your own group after all, so leave off the group restriction. Read
> up on UPG (user private groups) for more information.
>
> Using the symbolic modes is the modern way (modern as in as of around
> twenty years ago modern) and avoids the trap of hard setting all of
> the bits. I think they are easier for people to understand too. If
> you want to do it the old way with hard numbers then using 'find' is
> the way to go. And if you have messed things up then some creative
> find commands can repair things.
>
> Bob
>
> [1] http://www.gnu.org/software/coreutils/faq/#Why-can-only-root-chown-files_003f
>
Bob

Thanks for the excellent advice. I executed the command you suggested
and did so recursively and that has achieved the result I wanted.

Thanks for the information as well. My head always gets a little
muddled when it comes to setting permissions, so I'm glad I asked first.

Cheers

AG


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4C42BF4E.7040601(a)gmail.com
From: Rob Owens on 22 Jul 2010 17:30
On Sun, Jul 18, 2010 at 09:46:06AM +0100, AG wrote:
> On 17/07/10 22:19, Bob Proulx wrote:
>> AG wrote:
>>
>>> I have created another account for someone who will need to use my
>>> computer for a while. However, when checking this, I found that my own
>>> files are viewable from this second account.
>>>
>> By default files in the home are readable but not writable.
>>
>>
>>> How do I set the permissions so that the contents of my own /home/ag
>>> account are not viewable from the new user account?
>>>
>> $ chmod o-rwx ~/
>>
>> That is 'o' for 'other' minus read-write-execute permissions. You can
>> run that recursively if you like with 'chmod -R'.
>>
>>
>>> For obvious reasons, I want to be careful about the permissions I
>>> set so I don't lock myself out. I think that it is chown 700
>>> /home/ag -R but can someone please confirm that this will do what I
>>> want before I screw things up.
>>>
>> I commend you for asking. Using 'chown 700 /home/ag -R' would
>> probably fail but does something completely different on two counts.
>> One is that you want chmod not chown. 'chown 700' would try to change
>> the ownership to user number 700, but would probably fail since only
>> root can give away file ownership[1].
>>
>> But then if you had actually used 'chmod 700' it would be bad because
>> that hard sets the execute bit on every file! You don't want that
>> either. Also you really have no reason to lock out your own group, it
>> is your own group after all, so leave off the group restriction. Read
>> up on UPG (user private groups) for more information.
>>
>> Using the symbolic modes is the modern way (modern as in as of around
>> twenty years ago modern) and avoids the trap of hard setting all of
>> the bits. I think they are easier for people to understand too. If
>> you want to do it the old way with hard numbers then using 'find' is
>> the way to go. And if you have messed things up then some creative
>> find commands can repair things.
>>
>> Bob
>>
>> [1] http://www.gnu.org/software/coreutils/faq/#Why-can-only-root-chown-files_003f
>>
> Bob
>
> Thanks for the excellent advice. I executed the command you suggested
> and did so recursively and that has achieved the result I wanted.
>
> Thanks for the information as well. My head always gets a little
> muddled when it comes to setting permissions, so I'm glad I asked first.
>
You don't need to do it recursively. Simply removing the read and
execute permissions for "other" on your home directory is good enough.
This prevents anyone else from looking at any files within your home
directory, regardless of what the permissions on those specific files
is.

-Rob


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100722212702.GB11199(a)aurora.owens.net
 | 
Pages: 1
Prev: where's udevinfo ?
Next: Confirming submission of bug report