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.

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

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.

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

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

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.

john wrote:
> 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?

First of all, there are Debian specific ways of changing these defaults
- e.g. the permissions used creating a user's home directory, user's
default
umask, etc., e.g.:
login.defs(5)
adduser.conf(5)

Secondly, 755 permissions on a home directory doesn't necessarily make
the contents of the home directory insecure. It will allow reading of
the names of items (links) within the directory, and the ability to
stat(2)/lstat(2) them, but any additional access granted to items
within
the 755 directory depends upon the permissions of those items. If the
permissions are more stringent than 755, everyone will pretty much be
locked out of the directory - e.g. if read is denied, they can't get
the
names of the stuff in the directory, if "execute" (x) permission is
denied, they can't cd into the directory, and they can't access or stat
any items within the directory.

> 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?

This is a pretty typical scenario, e.g.:
drwxr-xr-x 2 root root 5120 Jan 15 11:29 /sbin
-rwxr-xr-x 1 root root 58348 Apr 22 2004 /sbin/ifconfig
Regular users can run ifconfig (useful if they want to examine the
configuration of an interface), but they generally wouldn't be able to
use ifconfig to change a configuration. Stuff like this tends to get
tucked away in /sbin and /usr/sbin as those are considered *S*ystem
binaries/programs. That doesn't mean users can never do anything with
them, but most of the time the casual user won't be interested in them.

Denying read and/or execute on such commonly available programs often
does little to nothing regarding security - e.g. if user can snag a
copy
of the program from elsewhere, or otherwise create a duplicate, then
they can generally read and execute that program with whatever
privileges their ID has (or lacks).

The requirement to be superuser (UID 0, typically root) isn't
necessarily hard coded into the applications/programs. In many cases
they attempt the privileged operation(s), and if run by a UID that
doesn't have sufficient privilege, various things the program attempts
will fail - and the better behaved programs will generally complain
fairly clearly about what couldn't be done or what failed - and perhaps
even why.
The 777 stuff you're seeing in /sbin is probably just symbolic links -
the permissions of symbolic links don't matter (except perhaps for
cosmetic purposes) - in the case of a symbolic link, what (if anything)
the symbolic link eventually resolves to is what matters.
shutdown(8) (e.g. see: /etc/shutdown.allow)
http://www.pathname.com/fhs/

On Mon, 13 Mar 2006 22:43:38 -0800, Michael Paoli wrote:

> john wrote:
>> 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?
>
> First of all, there are Debian specific ways of changing these defaults
> - e.g. the permissions used creating a user's home directory, user's
> default
> umask, etc., e.g.:
> login.defs(5)
> adduser.conf(5)

The default DIR_MODE in debian's adduser.conf is 755 and the default file
umask is 022, so it looks like home directories are world readable in
Debian. Does login.defs have any impact at all on Debian, given that Pam
is in use? Isn't the default umask set in /etc/profile anyway? If I can
set my own should it be in ~/.bashprofile or ~/.bashrc?

> Secondly, 755 permissions on a home directory doesn't necessarily
make > the contents of the home directory insecure. It will allow reading
of > the names of items (links) within the directory, and the ability to >
stat(2)/lstat(2) them, but any additional access granted to items > within
> the 755 directory depends upon the permissions of those items. If the >
permissions are more stringent than 755, everyone will pretty much be >
locked out of the directory - e.g. if read is denied, they can't get > the
> names of the stuff in the directory, if "execute" (x) permission is >
denied, they can't cd into the directory, and they can't access or stat >
any items within the directory.

I think there should be conservative, private settings "out of the box",
but that's just me.

>
>> 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? >
> This is a pretty typical scenario, e.g.: > drwxr-xr-x 2 root root 5120
Jan 15 11:29 /sbin > -rwxr-xr-x 1 root root 58348 Apr 22 2004
/sbin/ifconfig > Regular users can run ifconfig (useful if they want to
examine the > configuration of an interface), but they generally wouldn't
be able to > use ifconfig to change a configuration. Stuff like this
tends to get > tucked away in /sbin and /usr/sbin as those are considered
*S*ystem > binaries/programs. That doesn't mean users can never do
anything with > them, but most of the time the casual user won't be
interested in them. >
> Denying read and/or execute on such commonly available programs often >
does little to nothing regarding security - e.g. if user can snag a > copy
> of the program from elsewhere, or otherwise create a duplicate, then >
they can generally read and execute that program with whatever >
privileges their ID has (or lacks). > > The requirement to be superuser
(UID 0, typically root) isn't > necessarily hard coded into the
applications/programs. In many cases > they attempt the privileged
operation(s), and if run by a UID that > doesn't have sufficient
privilege, various things the program attempts > will fail - and the
better behaved programs will generally complain > fairly clearly about
what couldn't be done or what failed - and perhaps > even why.
> The 777 stuff you're seeing in /sbin is probably just symbolic links - >
the permissions of symbolic links don't matter (except perhaps for >
cosmetic purposes) - in the case of a symbolic link, what (if anything) >
the symbolic link eventually resolves to is what matters. > shutdown(8)
(e.g. see: /etc/shutdown.allow) > http://www.pathname.com/fhs/

I think the permissions system is a good tool, and not setting them
properly because "it probably won't help anyway" seems kind of flaky. The
rogue user who tries to install and run a rogue program should be defeated
by a well designed file permission system. That's the whole problem with
Windows is that permissions are too slack. Shouldn't linux try to build
on its strenths in this area?

I think Linux needs to improve by cleaning up the user interface. There
are too many ways to do things, config files that have to relevance
because another package is overriding it. eg login.defs overridden wholly
or partly by the existence of Pam. Debian installs both /etc/pam.d *and*
pam.conf - why the hell is that? Somewhere in the bowels of Pam is a
provision that says if both exist, then /etc/pam.d will determine the
configuration. Sheesh.

There should be *one way* to set something, and it should be effective and
well explained.

I was reading in Aileen Frisch's Essential System Administration book
about her recommendations for making system changes - one of them is "test
test test" before "releasing it on the world". If someone with her
experience and knowledge isn't sure what the effects of her system changes
will be, what chance does the average joe have to run a linux system
reliably and securely?

Debian should ship with *no servers* installed or running - by default.
And nice private settings for home directories - by default. People who
want to run servers will no doubt be able to figure out how to run them.
People who don't know that they shouldn't be running them will not be able
to stop them or even have much chance of realizing that they shouldn't be
running them.

I'm not trying to start any arguments either, just offering my opinions on
these issues, for what they are worth. Linux could be *so much better*
than windows, but changes need to be made to realize that potential.

I forgot to add that I think Debian should be leading the way, too.

john wrote:
> The default DIR_MODE in debian's adduser.conf is 755 and the default file
> umask is 022, so it looks like home directories are world readable in
> Debian. Does login.defs have any impact at all on Debian, given that Pam
> is in use? Isn't the default umask set in /etc/profile anyway? If I can
> set my own should it be in ~/.bashprofile or ~/.bashrc?

DIR_MODE in Debian's adduser.conf only impacts the mode of the home
directory when it's first created via adduser. UMASK in Debian's
login.defs can be used to set a umask value for login sessions. PAM
and other files can be used to set umask values. Depending on various
factors, potentially also including one's login shell, they will
generally apply in a hierarchial order. The higher up the setting is
made, the more "global" or "universal" it acts - at least as a
default. Typically users can tweak these to their liking, or insure
they get what they want, even if the system default is not to their
liking or preference, by suitably adjusting their startup file(s),
e.g. ~/.profile Where, and/or if one should set those in specific
file(s) depends upon when and how one wants them to take effect.

> I think there should be conservative, private settings "out of the box",
> but that's just me.
Reasonable opinions will differ. I tend to lean that direction, but
many environments favor a more "open" environment - e.g. sharing read
access to most or much stuff, unless otherwise explicitly denied. This
can also be easier (but less secure) for users not so familiar with
the permissions mechanisms of LINUX/UNIX/etc.

> I think the permissions system is a good tool, and not setting them
> properly because "it probably won't help anyway" seems kind of flaky. The
> rogue user who tries to install and run a rogue program should be defeated
> by a well designed file permission system. That's the whole problem with
> Windows is that permissions are too slack. Shouldn't linux try to build
> on its strenths in this area?

Well, "properly" may be a subject of debate - as to its definition,
for starters. Making something readable and/or executable
(particularly also if it lacks SUID/SGID), particularly if it's quite
commonly available elsewhere anyway, and nothing would prevent the
user from writing out a similar binary (and owning it and setting the
permissions to their liking), then denying read/execute on it isn't
all that useful in general. E.g. I can think of a particular
commercial UNIX where the vendor has ntpdate readable, but not
executable, for ordinary users. I find this a futile waste, as I
occasionally want to run ntpdate (with the -u and -q options) as a
mere mortal user on said UNIX - so what do I end up doing? I copy the
binary, set the execute permission on the copy, and run that. It's
rather wasteful, but it's more secure than my becoming superuser just
to run the binary in the same manner. Likewise for fuser on some
commercial UNIX flavor(s). Denying users access to this kind of stuff
often ends up with lots more copies of such running around the system
anyway.

> I think Linux needs to improve by cleaning up the user interface. There
> are too many ways to do things, config files that have to relevance
> because another package is overriding it. eg login.defs overridden wholly
> or partly by the existence of Pam. Debian installs both /etc/pam.d *and*
> pam.conf - why the hell is that? Somewhere in the bowels of Pam is a
> provision that says if both exist, then /etc/pam.d will determine the
> configuration. Sheesh.

> There should be *one way* to set something, and it should be effective and
> well explained.

In UNIX and LINUX, there are often many ways to do things. This is
generally a good thing. One can pick the most efficient, or the one
one is most familiar with. I think many folks prefer not being told
that there's only one way to do something and if you want to do it you
must do it only that way, and no other way. By the time you get down
to the system call level, there often may only be one way to do
something, but at higher levels of abstraction and commands, there are
often multiple ways to accomplish the same tasks or effects.

> I was reading in Aileen Frisch's Essential System Administration book
> about her recommendations for making system changes - one of them is "test
> test test" before "releasing it on the world". If someone with her
> experience and knowledge isn't sure what the effects of her system changes
> will be, what chance does the average joe have to run a linux system
> reliably and securely?

Yes, good book, good advice. There's lots of great documentation out
there, but sometimes the documentation isn't fully clear, complete,
and correct. Testing is generally a good thing. Also, with, e.g.
Debian, if/when one finds the documentation in error or missing
crucial information, one has better opportunities to submit that
information, and it's more likely to actually get included in future
releases.

> Debian should ship with *no servers* installed or running - by default.
> And nice private settings for home directories - by default. People who
> want to run servers will no doubt be able to figure out how to run them.
> People who don't know that they shouldn't be running them will not be able
> to stop them or even have much chance of realizing that they shouldn't be
> running them.

If one merely does the "base" install on Debian, I think one does get
that situation - no "servers" running - at least not any network
services, ... or at least exceedingly close to it. There's a
trade-off here between ease-of-use and security. Some systems (e.g.
OpenBSD) lean more towards security - no running network servers by
default, when the programs are added, by default they don't start,
etc. This can be rather painful, however, for those less familiar
with UNIX/LINUX/BSD - often they want and expect, that when they
install some network service package (e.g. Apache), that they ought to
get a good working default configuration to start off with, and that
it should be reasonably secure by default, but it should be
functioning and operational. Many vendors/distributions play this
balance between security and ease-of-use, landing various places along
that spectrum.

Personally, what I'd like to see and advocate, is a relatively
high-level configuration file, that one could set and specify how one
wants
these things to behave by default, e.g. something roughly like:
#NEWLY_INSTALLED_SERVER_STARTS_BY_DEFAULT=YES
NEWLY_INSTALLED_SERVER_STARTS_BY_DEFAULT=NO
#NEWLY_UPGRADED_SERVER_STARTS_OR_RESTARTS_BY_DEFAU LT=YES

#NEWLY_UPGRADED_SERVER_STARTS_OR_RESTARTS_BY_DEFAU LT=IF_ENABLED_IN_CONFIG
#IF_ENABLED_IN_CONFIG would suitably consult [x]inetd.conf, rc files
#and run state, and configuration for that server service

#would restart it if the upgrade first stopped running server
#NEWLY_UPGRADED_SERVER_STARTS_OR_RESTARTS_BY_DEFAU LT=IF_WAS_RUNNING

NEWLY_UPGRADED_SERVER_STARTS_OR_RESTARTS_BY_DEFAUL T=NO

> I'm not trying to start any arguments either, just offering my opinions on
> these issues, for what they are worth. Linux could be *so much better*
> than windows, but changes need to be made to realize that potential.

LINUX (and Debian) *is* *so much better*! ... but that's for
comp.os.linux.advocacy

john wrote:
> I forgot to add that I think Debian should be leading the way, too.

To a large extent, Debian is leading the way. If you look at usage of
major LINUX distributions, and how many of them are based upon or use
much from Debian, and also Debian's influence on LSB, DCC, UNIX and
BSD and other standards, Debian is a major player, and in many areas
leading the way (if not directly, at least by influence and
contributions).

Thanks for the detailed post. Along with your configuration page for
servers I would offer the following:

Put all the configuration for any given package in one subdirectory. That
would mean /etc/security would move to pam.d. Simplify simplify. There
is no good argument for unnecessary complexity.

In my short linux history I definitely see progress though - kernel
configuration is improving rapidly. I wonder why it is so difficult to
make similar rapid improvements to the debian-installer? It looks like it
should be easy.

Maybe I will take back all my suggestions after I get my copy of Martin
Kraffts book and understand the big picture better. :-)

Thanks again.