By default, new users are made members of a group with the users assigned
user name.  The user's homedirectory is therefore "username".

I decided to change the permissions on this subdirectory as follows:

chmod 2700 username

My understanding was that all files created underneath /home/username
would then be owned by username and group username with permissions 700
but this doesn't seem to be the case.

touch somefile, executed within my home directory has file permissions of
644!  If I make the file executable, the permissions change to 755.

What do I not understand about this?  I thought the file permissions were
going to be the same as the permissions on /home/username.

[ Post a follow-up to this message ]

On Sun, 12 Mar 2006 15:00:45 GMT, john
<john@somewhere.com> wrote:
> By default, new users are made members of a group with the users assigned
> user name.  The user's homedirectory is therefore "username".
>
> I decided to change the permissions on this subdirectory as follows:
>
> chmod 2700 username
>
> My understanding was that all files created underneath /home/username
> would then be owned by username and group username with permissions 700
> but this doesn't seem to be the case.
>
> touch somefile, executed within my home directory has file permissions of
> 644!  If I make the file executable, the permissions change to 755.
>
> What do I not understand about this?  I thought the file permissions were
> going to be the same as the permissions on /home/username.

The permissions of files you create are determined by your umask, which
can be set in /etc/profile or ~/.bashrc.

--
After 14 non-maintainer releases, I'm the S-Lang non-maintainer.
-- Ray Dassen

[ Post a follow-up to this message ]

john wrote:
> I decided to change the permissions on this subdirectory as follows:
> chmod 2700 username
> My understanding was that all files created underneath /home/username
> would then be owned by username and group username with permissions 700
> but this doesn't seem to be the case.

Read The Fine Manual (RTFM) :-) ...

references/excerpts:
open(2)
O_CREAT
If  the file does not exist it will be created.  The
owner (user
ID) of the file is set to the effective user ID of the
process.
The  group  ownership  (group ID) is set either to the
effective
group ID of the process or to the group ID of the parent
direc-
tory  (depending  on  filesystem type and mount options,
and the
mode of the parent directory, see, e.g., the mount
options  bsd-
groups  and  sysvgroups  of the ext2 filesystem, as
described in
mount(8)).
The argument mode specifies the permissions to use in case a
new  file
is created. It is modified by the process's umask in the usual
way: the
permissions of the created file are (mode & ~umask).   Note
that  this
mode  only  applies  to  future accesses of the newly created
file; the
open call that creates a read-only file may well  return  a
read/write
file descriptor.
mkdir(2)
mkdir attempts to create a directory named pathname.
The  parameter mode specifies the permissions to use. It is
modified by
the process's umask in the usual way: the permissions  of  the
created
directory  are  (mode & ~umask & 0777).  Other mode bits of the
created
directory depend on the operating system.  For Linux, see below.
The newly created directory will be owned by the effective user
ID  of
the process.  If the directory containing the file has the set
group ID
bit set, or if the filesystem is mounted with BSD group
semantics,  the
new  directory will inherit the group ownership from its parent;
other-
wise it will be owned by the effective group ID of the process.
If the parent directory has the set group ID bit set then so
will  the
newly created directory.

[ Post a follow-up to this message ]

On Sun, 12 Mar 2006 18:18:03 -0800, Michael Paoli wrote:

> john wrote: 
>
> Read The Fine Manual (RTFM) :-) ...
>
> references/excerpts:
> open(2)
>        O_CREAT
>               If  the file does not exist it will be created.  The
> owner (user
>               ID) of the file is set to the effective user ID of the
> process.
>               The  group  ownership  (group ID) is set either to the
> effective
>               group ID of the process or to the group ID of the parent
> direc-
>               tory  (depending  on  filesystem type and mount options,
> and the
>               mode of the parent directory, see, e.g., the mount
> options  bsd-
>               groups  and  sysvgroups  of the ext2 filesystem, as
> described in
>               mount(8)).
>        The argument mode specifies the permissions to use in case a
> new  file
>        is created. It is modified by the process's umask in the usual
> way: the
>        permissions of the created file are (mode & ~umask).   Note
> that  this
>        mode  only  applies  to  future accesses of the newly created
> file; the
>        open call that creates a read-only file may well  return  a
> read/write
>        file descriptor.
> mkdir(2)
>        mkdir attempts to create a directory named pathname.
>        The  parameter mode specifies the permissions to use. It is
> modified by
>        the process's umask in the usual way: the permissions  of  the
> created
>        directory  are  (mode & ~umask & 0777).  Other mode bits of the
> created
>        directory depend on the operating system.  For Linux, see below.
>        The newly created directory will be owned by the effective user
> ID  of
>        the process.  If the directory containing the file has the set
> group ID
>        bit set, or if the filesystem is mounted with BSD group
> semantics,  the
>        new  directory will inherit the group ownership from its parent;
> other-
>        wise it will be owned by the effective group ID of the process.
>        If the parent directory has the set group ID bit set then so
> will  the
>        newly created directory.

Thanks for the responses.  I am clearly way off track with my original
post.  This exercise started out with me being curious about why my home
directory had permissions 755 on it.  I'm the only one using the machine
so it' pretty much an academic exercise, but surely it's not right to have
those permissions on everyone's home directory, is it?  Is everyone's home
directory world readable by design?

I thought the setgid permission on the home directory had the effect of
setting the group ownership *and* the mode of all the files within the
directory.  I understand now that it only sets the group ownership of
files in the subdirectory.

I will do the reading and see if I can completely understand all the
factors that effect how modes are set.  Again, thanks for the pointers to
more information.  Clearly, there are a few levels of detail to understand.

Permissions seem to be somewhat confusing.  For example, the permissions
on the /sbin directory are 755 and the files within /sbin are also 755,
except for a few that are 777.  Seems really strange.  I can change into
the subdirectory but I can't run "shutdown" as a normal user - it says
"you have to be root to do that".  Fine.  If I run modprobe -r somedriver
(not being used, according to lsmod) modprobe objects but doesn't tell me
why.  If these binaries are not to be run by ordinary users, why are the
permissions set the way they are?  Why not just set them to 700 in every
case?  Why hardcode the requirement to be root right into the executable
(which seems like it might be prone to error), and then set the file
permissions to 755 ??  Or why take care to exclude sbin from the
path of the normal user, then let him wander around in there?

Very strange.  Bizarre even.

[ Post a follow-up to this message ]