Why can you hardlink to any file? (Postfix spool etc..)
David Malone
Does anyony know why you can make hardlinks to files you can't
write to? Is it just tradition or are there some applications
which actually use this for something important?
Just as a test I got my kernel at home to log whenever a link
was made to a file that couldn't be written to by that user.
This is on FreeBSD 2.2-STABLE and I ran all the daily, weekly
and monthly jobs and then did a "make world" and not one thing
in all of that logged a message.
If I have a chance I'll try this experiment in college where
the machines get much more use in a greater variety of ways,
but it looks like nothing I do makes use of this feature of
hard links. Maybe it should be tunable option?
David.
Barry Margolin
David Malone <dwma...@maths.tcd.ie> wrote:
>Does anyony know why you can make hardlinks to files you can't
>write to? Is it just tradition or are there some applications
>which actually use this for something important?
What does writability have to do with making a link? Suppose you just want
to read the file, why shouldn't you be able to make a link and use it?
Since you're bringing it up, why *shouldn't* you be able to make hardlinks
to files you can't write? What problems are created by being able to do
so?
>Just as a test I got my kernel at home to log whenever a link
>was made to a file that couldn't be written to by that user.
>This is on FreeBSD 2.2-STABLE and I ran all the daily, weekly
>and monthly jobs and then did a "make world" and not one thing
>in all of that logged a message.
Hard links aren't used very much these days, for both writable and
non-writable files. Symbolic links suffice for most purposes.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
Nick Maclaren
Barry Margolin <bar...@bbnplanet.com> wrote:
>In article <77ggsk$n...@walton.maths.tcd.ie>,
>David Malone <dwma...@maths.tcd.ie> wrote:
>>Does anyony know why you can make hardlinks to files you can't
>>write to? Is it just tradition or are there some applications
>>which actually use this for something important?
>
>What does writability have to do with making a link? Suppose you just want
>to read the file, why shouldn't you be able to make a link and use it?
>
>Since you're bringing it up, why *shouldn't* you be able to make hardlinks
>to files you can't write? What problems are created by being able to do
>so?
Think quotas. The owner 'deletes' a file, but - lo! and behold! - his
allocation does not decrease. If you are careful, he can't even find
out who is keeping that file around.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Jon Ribbens
On Thu, 14 Jan 1999 21:53:21 GMT, Barry Margolin <bar...@bbnplanet.com> wrote:
>Since you're bringing it up, why *shouldn't* you be able to make hardlinks
>to files you can't write? What problems are created by being able to do
>so?
It's bizarre and causes unexpected effects.
An instant example: suppose user A has a large file which is visible to
user B. (Not necessarily readable by, user B just has to be able to see
its directory entry.) User B makes a hard link to the file in their home
directory. User A now wants to delete the file, perhaps to make some
room in their quota for other files. They *can't*. It's their file, but
they can't delete it without user B's permission.
Another problem, is that user B can make user A's files appear in
unexpected locations in the filing system, where they may have special
significance, without user A's permission or knowledge.
Cheers
Jon
--
\/ Jon Ribbens / j...@oaktree.co.uk
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBNp5vHIMzEl4yn7LtAQECQQP/ftM1z7EsLEdFA2YbVQXAmmmtfw5KdIus
nneri5Jk3PkeTNSSXpdpF5PdjDtFpYMIOqXIVL4+xHx0PvNMJthEDyyq0m3ulvhU
qGyGErrPqLdKanQACuOUs4M00XVkOH35FY4tOJjgFO1/jbxc306SmBk4Aw7PfYM+
pPggf7iRe5I=
=EYv3
-----END PGP SIGNATURE-----
Matthew Whelan
>
> Does anyony know why you can make hardlinks to files you can't
> write to? Is it just tradition or are there some applications
> which actually use this for something important?
>
Setting up chrooted environments - you can't symlink out of the chrooted
environment, so in order to see files outside without having to create
another copy, you either need to hardlink them, or create a loopback
mount. If therefore you want to access a read-only file in some
directory without providing access to the rest of the directory, you
need a hardlink.
~ Matthew ~
Richard Jones
: -----BEGIN PGP SIGNED MESSAGE-----
: On Thu, 14 Jan 1999 21:53:21 GMT, Barry Margolin <bar...@bbnplanet.com> wrote:
:>Since you're bringing it up, why *shouldn't* you be able to make hardlinks
:>to files you can't write? What problems are created by being able to do
:>so?
: It's bizarre and causes unexpected effects.
: An instant example: suppose user A has a large file which is visible to
: user B. (Not necessarily readable by, user B just has to be able to see
: its directory entry.) User B makes a hard link to the file in their home
: directory. User A now wants to delete the file, perhaps to make some
: room in their quota for other files. They *can't*. It's their file, but
: they can't delete it without user B's permission.
: Another problem, is that user B can make user A's files appear in
: unexpected locations in the filing system, where they may have special
: significance, without user A's permission or knowledge.
Another problem happens when /home and /usr
are on the same partition (not a recommended
configuration, I know, but ...). That old
version of sendmail with lots of bugs in
it? You (the admin) delete it and replace it
with a newer version, but one of your users
put in a hard link to the file, and so they
*still* have access to the old buggy possibly
setuid version ...
Oops ...
Rich.
--
- Richard Jones. Linux contractor London and SE areas. -
- Very boring homepage at: http://www.annexia.demon.co.uk/ -
- You are currently the 1,991,243,100th visitor to this signature. -
- Original message content Copyright (C) 1998 Richard Jones. -
D. J. Bernstein
own the target file? Would this eliminate any good uses of link()?''
The answer to the second question is no.
Matthew Whelan <mp...@cam.ac.uk> wrote:
> Setting up chrooted environments
Such environments are set up by root; of course root can make links.
---Dan
D. J. Bernstein
[ quotas affected by hard links from other users ]
> The owner 'deletes' a file, but - lo! and behold! - his
> allocation does not decrease.
Of course, even without links, the attacker can prevent deallocation of
any world-readable file.
A good target on big systems is the password database: it's fairly
large, stored on the root disk, updated with rename(), and subject to
frequent updates. Impact: Unless the root disk is huge, an attacker can
fill it up, breaking all sorts of programs. This is something that
legitimate programs might do by accident. There's no serious logging.
If the BSD revoke() syscall were portable, and applicable to regular
files, then it would solve the problem in situations where nobody's
supposed to be looking at the old file: the owner could call chmod(),
revoke(), unlink(). But files such as the password database need to
permit access for at least a little while after updates.
Does the system really need any frequently updated world-readable files?
Consider, for example, the login shells listed in /etc/passwd. Why can't
a user's shell be specified somewhere in his home directory?
---Dan
Matthew Whelan
Good point - but it does leave the need for at least root to be able to
do so. I guess it could be re-written so that only root can set
hardlinks to readonly files without really losing anything. Unless you
were on a large system with lots of chrooted environments such that root
had to farm out their administration once set up to trusted users - but
then i dont know how good an idea that would be.
~ Matthew ~
Matthew Kirkwood
> A good target on big systems is the password database: it's fairly
> large, stored on the root disk, updated with rename(), and subject to
> frequent updates. Impact: Unless the root disk is huge, an attacker can
> fill it up, breaking all sorts of programs. This is something that
> legitimate programs might do by accident. There's no serious logging.
>
> If the BSD revoke() syscall were portable, and applicable to regular
Linux (so far :) and Irix lack it. Are there any others?
> files, then it would solve the problem in situations where nobody's
> supposed to be looking at the old file: the owner could call chmod(),
> revoke(), unlink(). But files such as the password database need to
There's a race in there. frevoke() is probably required to fix this (or
linking into a mode 700 directory, unlinking the original and revoke()ing
the new one).
[ I did a (slightly dodgy) implementation of revoke() for Linux about a
year ago which wasn't good enough to be accepted, but not exciting enough
for someone else to do it properly.. =]
> permit access for at least a little while after updates.
>
> Does the system really need any frequently updated world-readable files?
> Consider, for example, the login shells listed in /etc/passwd. Why can't
> a user's shell be specified somewhere in his home directory?
Why can't his password be stored somewhere similar, too?
Matthew.
Nick Maclaren
In article <1999Jan1504...@koobera.math.uic.edu>, d...@koobera.math.uic.edu (D. J. Bernstein) writes:
|> Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
|> [ quotas affected by hard links from other users ]
|> > The owner 'deletes' a file, but - lo! and behold! - his
|> > allocation does not decrease.
|>
|> Of course, even without links, the attacker can prevent deallocation of
|> any world-readable file.
Over a reboot? There aren't many systems that are NEVER rebooted.
|> A good target on big systems is the password database: it's fairly
|> large, stored on the root disk, updated with rename(), and subject to
|> frequent updates. Impact: Unless the root disk is huge, an attacker can
|> fill it up, breaking all sorts of programs. This is something that
|> legitimate programs might do by accident. There's no serious logging.
It depends. On several of the systems that I manage, the root file
system has very few files that the user can fill up without being
identified and jumped on. Most of the large, rubbish-accumulating
files are in /var. There is certainly no serious logging.
|> Does the system really need any frequently updated world-readable files?
Theoretically, it doesn't. In practice, we are stuck with Unix as
she is broke.
|> Consider, for example, the login shells listed in /etc/passwd. Why can't
|> a user's shell be specified somewhere in his home directory?
That is a good source of security problems. The user's login shell
is often used (a) for a test to tell if the user is 'normal' and
(b) from privileged code with a known argument and only half-baked
reduction of privilege. I know that both are stupid ideas, but many
programs are stupid.
Greg Andrews
>
>It's bizarre and causes unexpected effects.
>
>An instant example: suppose user A has a large file which is visible to
>user B. (Not necessarily readable by, user B just has to be able to see
>its directory entry.) User B makes a hard link to the file in their home
>directory. User A now wants to delete the file, perhaps to make some
>room in their quota for other files. They *can't*. It's their file, but
>they can't delete it without user B's permission.
>
What are you talking about. User A owns the file. What part of
Unix would prevent User A from deleting a file he/she owns?
User A may not be aware of the whereabouts of the link created
by User B, but that's not a permission issue.
>
>Another problem, is that user B can make user A's files appear in
>unexpected locations in the filing system, where they may have special
>significance, without user A's permission or knowledge.
>
User B can't create a link in a directory that he/she can't write to.
Where can User B, as an unprivileged user, create a file that has
"special significance"? If there is such a place, it sounds like
a rather significant security hole on that machine.
-Greg
Greg Andrews
>
>Another problem happens when /home and /usr
>are on the same partition (not a recommended
>configuration, I know, but ...). That old
>version of sendmail with lots of bugs in
>it? You (the admin) delete it and replace it
>with a newer version, but one of your users
>put in a hard link to the file, and so they
>*still* have access to the old buggy possibly
>setuid version ...
>
>Oops ...
>
Rename the one on /usr to sendmail.old, and chmod it to 400.
The user's hard link will fail rather than invoke the buggy
version.
But you reveal another thing admins should do when upgrading
versions of important programs: check the link count and
verify all the hard links before simply deleting the old
binary.
-Greg
David Malone
>What are you talking about. User A owns the file. What part of
>Unix would prevent User A from deleting a file he/she owns?
You can only delete a (link to a) file if you can write to
the directory it is in.
David.
Alun Jones
The final part of the puzzle is that the file stays in existence until all
links to it are gone. As noted elsewhere, your quota may be affected if the
file hangs around, even though you believe it's gone.
Alun.
~~~~
--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613 | us at al...@texis.com. VISA / MC accepted.
Fax +1 (512) 378 3246 | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*WFTPD and WFTPD Pro now available as native Alpha versions for NT*
Barry Margolin
Richard Jones <ri...@annexia.demon.co.uk> wrote:
>Jon Ribbens <j...@oaktree.co.uk> wrote:
>: An instant example: suppose user A has a large file which is visible to
>: user B. (Not necessarily readable by, user B just has to be able to see
>: directory. User A now wants to delete the file, perhaps to make some
>: room in their quota for other files. They *can't*. It's their file, but
>: they can't delete it without user B's permission.
>
>: unexpected locations in the filing system, where they may have special
>: significance, without user A's permission or knowledge.
>
>are on the same partition (not a recommended
>configuration, I know, but ...). That old
>version of sendmail with lots of bugs in
>it? You (the admin) delete it and replace it
>with a newer version, but one of your users
>put in a hard link to the file, and so they
>*still* have access to the old buggy possibly
>setuid version ...
What does the writability of the file have to do with either of these
examples? The message I was responding to was specifically complaining
about the ability to make hard links to files that you don't have write
permission for. The above situations suggest why hard links shouldn't be
allowed *at all*, but not why they should be allowed for writable files but
disallowed for unwritable files.
In fact, the first example would be even worse if the file were writable.
Suppose A had a *small* file which is writable by user B. User B makes a
hard link to the file in their directory. User A deletes the file. User B
then writes an enormous amount of data to the file, causing A to exceed his
quota.
Barry Margolin
David Malone <dwma...@maths.tcd.ie> wrote:
>ge...@shell1.ncal.verio.com (Greg Andrews) writes:
>
>>What are you talking about. User A owns the file. What part of
>>Unix would prevent User A from deleting a file he/she owns?
>
>You can only delete a (link to a) file if you can write to
>the directory it is in.
And before someone suggests that the owner can still truncate the file in
B's directory (if he knows it's there), that may not be possible either.
In order to access a file by a particular pathname, you have to have
execute permission to all the directories in the pathname. B could put his
link in a directory to which only he has execute permission.
David Malone
>1995: ``Would POSIX allow link() to deny permission if the user doesn't
>own the target file? Would this eliminate any good uses of link()?''
>The answer to the second question is no.
Where can I find the original version of this discussion? I had a quick
look on dejanews, altavista and bugtraq and didn't find it.
David.
David Malone
>In article <rg1m77...@gw.annexia.org>,
>What does the writability of the file have to do with either of these
>examples? The message I was responding to was specifically complaining
>about the ability to make hard links to files that you don't have write
>permission for. The above situations suggest why hard links shouldn't be
>allowed *at all*, but not why they should be allowed for writable files but
>disallowed for unwritable files.
Indeed, hard linkability should probably be the same as chmodability
and chgrpability.
(As a side note it also lets people change the ctime of files - which
suggests that it should probably be the same class of thing as chmoding).
David.
Barry Margolin
David Malone <dwma...@maths.tcd.ie> wrote:
>Indeed, hard linkability should probably be the same as chmodability
>and chgrpability.
In other words, only the owner or root should be able to do it.
In the last thread where we discussed this (I think it was the one about
Postfix security holes), I mentioned that there are some applications that
make use of hard links as a mutual exclusion mechanism; they take advantage
of the fact that link(2) and rename(2) are atomic (on local file systems).
I believe they almost always make the link in the same directory as the
original, so hard linking within a directory would probably have to be
permitted to keep from breaking them. Since things like the Postfix
security hole presumably involve linking from the spool to a system
directory (e.g. /etc or /usr/bin) this loophole would not open those holes
back up.
Richard Jones
[RJ's buggy sendmail example deleted]
: What does the writability of the file have to do with either of these
: examples? The message I was responding to was specifically complaining
: about the ability to make hard links to files that you don't have write
: permission for. The above situations suggest why hard links shouldn't be
: allowed *at all*, but not why they should be allowed for writable files but
: disallowed for unwritable files.
It's more about `control' than writability. OK, so sendmail
isn't writable by user, but that's not the issue. The issue
is that the user takes control of a file which (one would
assume) should be under the control of the admin.
Having said that, I think hard links are a great idea, and,
apart from some problems which can be worked around (eg. by
having /usr and /home on separate partitions, which is good
admin practice *anyway* - to avoid the user filling the /usr
partition), they are more useful than not useful, so I don't
think we are really in disagreement.
Mike O'Dell
the discussions which resulted in soft links being added
and there was a *LOT* of discussion around getting the
corner cases right.
in Unix, files are not deleted; you can remove your
contribution to the reference count on a file, but you
cannot "remove" the file. if the reference count goes to
zero, the system removes it. (having a file open also
increments the reference count - this is why you can
"remove" the reference to an open /tmp file and the
contents remains present but inaccessible to others until
you close it)
creating a hard link increments the reference count; unlinking
decrements the reference count.
the ability to "hand-off" files between UIDs (and
implicitly between directories) without implying anything
about access rights to the contents is actually *very*
useful. it is *profoundly* difficult to implement "slot in
the door" type functions without the reference count
semantics. anyone who has done a homework submission system
has used this trick, for instance.
soft links are essentially a simple macro processor which
manipulates path names without messing with reference
counts. this is also very useful but in very different
contexts - most importantly, they work across filesystems
where the dangling reference problem posed by hard links is
intractable.
hard links and soft links do subtly different things. there are jobs
that each one can do that the other cannot do. and there are unique
liabilities as there are unique strengths.
Some file systems do directories entirely with string algebra,
others do it entirely with data structures. Unix offered
both.
Unix without soft links is much more painful, but Unix without
hard links is unworkable. anyone who has tried to duplicate
Unix semantics on other operating systems has discovered the
subtleties of Unix reference counting (which is uses in more than
just link counts) the hard way. Unix admits beautifully simple
solutions to problems which are very hard to accomplish on
other systems.
-mo
Michael David Jones
>the semantics of links are very subtle. i was lurking at
>the discussions which resulted in soft links being added
>and there was a *LOT* of discussion around getting the
>corner cases right.
Indeed they are. See below.
>in Unix, files are not deleted; you can remove your
>contribution to the reference count on a file, but you
>cannot "remove" the file. if the reference count goes to
>zero, the system removes it. (having a file open also
>increments the reference count - this is why you can
>"remove" the reference to an open /tmp file and the
>contents remains present but inaccessible to others until
>you close it)
>creating a hard link increments the reference count; unlinking
>decrements the reference count.
You're confusing two concepts there. In the inode, there is both a
"link count" and a "reference count" field. The link count is
incremented every time a link is made from a directory to the inode.
The reference count is incremented every time the file is opened. When
a file is deleted (using rm), what happens is
1. the directory entry corresponding to the name given to rm is deleted
2. the link count in the inode is decremented.
3. *if* the link count and the ref count are *both* zero, the inode
(and associated data blocks) are freed.
As a corollary to 3, when a file is closed (and the ref count is
decremented), the same checks are made.
Mike Jones | jon...@rpi.edu
The greatest dangers to liberty lurk in insidious encroachment by men
of zeal, well-meaning but without understanding.
- Justice Louis D. Brandeis
Barry Margolin
>Unix without soft links is much more painful, but Unix without
>hard links is unworkable.
I disagree. While the open file reference count feature is quite nice, the
need for multiple directory entries pointing to the same inode is hardly
critical. The OS currently makes use of the same underlying mechanism (the
reference count in the in-core inode), this is not really necessary. It's
already the case that the in-core inode's reference count is different than
the on-disk inode's reference count when the file is open (so that fsck
will know that it's safe to get rid of a file if the system crashes while a
deleted file was open). If the disk inode didn't have a reference count,
the memory inode reference count could still have this, to support deleting
open files.
Hard links are mostly a historical remnant. The original Unix didn't have
symbolic links, possibly because the designers felt their clever hard link
mechanism could fill the need (it's not like they didn't know about the
concept -- Multics had multiple names for a file within the same directory
(called "addnames", after the command used to create them) and symbolic
links for all other cross-references, but nothing like hard links). But
when symbolic links were added, they quickly supplanted hard links. Except
for the use of hard links as simple mutexes in many existing applications,
which I've mentioned before, I think we could probably live without hard
links completely.
D. J. Bernstein
> implicitly between directories) without implying anything
> about access rights to the contents is actually *very*
> useful.
Are you claiming that there's some commonly used program that needs to
make links to files that it doesn't own?
---Dan
D. J. Bernstein
> There's a race in there.
No, there isn't. The procedure I described guarantees that the file is
gone, under the stated hypothesis that the attacker does not use link().
If the attacker is allowed to use link(), the problem is hopeless. Your
suggestion---moving the file to a protected directory before removing
it---doesn't stop the attack.
[ login shell specified in home directory ]
> Why can't his password be stored somewhere similar, too?
User-selected passwords can indeed be stored in ~user. System-generated
passwords can be stored in a file that isn't subject to common updates.
Mixed passwords, combining the worst features of user-selected passwords
and system-generated passwords, can be eliminated.
Of course, the attack I've mentioned doesn't apply to /etc/shadow, since
/etc/shadow isn't world-readable.
---Dan
D. J. Bernstein
> Where can I find the original version of this discussion?
My article appears below. I don't have a complete copy of the thread.
---Dan
From: d...@silverton.berkeley.edu (D. J. Bernstein)
Message-ID: <1995Mar1409...@silverton.berkeley.edu>
Date: 14 Mar 1995 09:48:17 GMT
Newsgroups: comp.security.unix
Subject: Re: Hard link a "security" hole?
References: <3k1pl2$i...@neptune.ethz.ch>
Organization: IR
In article <3k1pl2$i...@neptune.ethz.ch>,
Frank Richard Ammeter <famm...@iiic.ethz.ch> wrote:
> Can't hard links be a problem (circumventing quota and the like) ?:
Yes.
One solution to this type of problem: Prevent each user from exposing
his files to any other user. This means (1) eliminating all publicly
writable directories; (2) hiding user U's home directory inside a
rwxr-x--- directory, owned by root, in group G, where U is the only
member of group G.
Would POSIX allow link() to deny permission if the user doesn't own the
target file? Would this eliminate any good uses of link()?
---Dan
James Hu
I can think of a use case. A file server is serving a deliver file
request to a client. The server makes a hardlink to the requested
file, them mmap's the hardlink and delivers the contents of the file
to the client. After finishing, the server unlinks. If a user on the
server machine modifies the original file while delivery is in
progress, it does not corrupt the mmap'd copy that is in transit.
As to whether or not this is commonly done, I don't know. It would be
a reasonable approach, though.
--
James C. Hu <j...@cs.wustl.edu> Computer Science Doctoral Candidate
http://www.cs.wustl.edu/~jxh/ Washington University in Saint Louis
>>>>>>>>>>>>> I use *SpamBeGone* <URL:http://www.internz.com/SpamBeGone/>
Barry Margolin
James Hu <j...@cs.wustl.edu> wrote:
>I can think of a use case. A file server is serving a deliver file
>request to a client. The server makes a hardlink to the requested
>file, them mmap's the hardlink and delivers the contents of the file
>to the client. After finishing, the server unlinks. If a user on the
>server machine modifies the original file while delivery is in
>progress, it does not corrupt the mmap'd copy that is in transit.
Why is a hard link needed for this? Why doesn't it just mmap the named
file? mmap works on an open file descriptor, so it doesn't matter what
name was used to open it.
Nick Maclaren
>> Where can I find the original version of this discussion?
>
>My article appears below. I don't have a complete copy of the thread.
>
>---Dan
>
>From: d...@silverton.berkeley.edu (D. J. Bernstein)
>Message-ID: <1995Mar1409...@silverton.berkeley.edu>
>Date: 14 Mar 1995 09:48:17 GMT
>Newsgroups: comp.security.unix
>Subject: Re: Hard link a "security" hole?
>References: <3k1pl2$i...@neptune.ethz.ch>
>Organization: IR
>
>In article <3k1pl2$i...@neptune.ethz.ch>,
>Frank Richard Ammeter <famm...@iiic.ethz.ch> wrote:
>> Can't hard links be a problem (circumventing quota and the like) ?:
>
>Yes.
>
>One solution to this type of problem: Prevent each user from exposing
>his files to any other user. This means (1) eliminating all publicly
>writable directories; (2) hiding user U's home directory inside a
>rwxr-x--- directory, owned by root, in group G, where U is the only
>member of group G.
Why not go the whole hog, and disallow the user to access any files
outside his home directory, or even any files at all? You would have
SO much less trouble :-)
That "solution" has been proposed ad nauseam since long before Unix
existed by people who haven't thought things through. It is a
complete disaster in most environments, at least where the users are
trying to do some real work. Most serious work involves a degree
of collaboration - if you forbid any kind of file sharing, people
waste time bypassing your damn-fool restrictions, and often create
worse problems while doing it.
This has been observed time and again, and again, and again :-(
>Would POSIX allow link() to deny permission if the user doesn't own the
>target file? Would this eliminate any good uses of link()?
No. I doubt it.
James Hu
>In article <slrn7a0hr...@jamespc.ungerhu.com>,
>James Hu <j...@cs.wustl.edu> wrote:
>>I can think of a use case. A file server is serving a deliver file
>>request to a client. ...
>Why is a hard link needed for this? Why doesn't it just mmap the named
>file? mmap works on an open file descriptor, so it doesn't matter what
>name was used to open it.
The server may be servicing a receive file request clobbering the same
file it is delivering.
Mike O'Dell
no, i don't think i'm confusing things.
i may be thinking about it slightly differently, though,
as i look at it as a specific instance of Unix's reliance
on reference-count based sharing which pervades the design.
if you design a filesystem using reference counts, the
general problems to solve are providing for persistent
storage of the reference counts and managing the
maintenance of that persistent storage. this revolves
around managing the transition of the reference count
object between active instatiation in an execution context
and the static instantiation in persistent storage.
with that as context:
the inode is where the reference count is stored when it is
not stored in kernel data structures. if the file is not
open, the only references are pointers from directory
entries in the filesystem and that exactly corresponds to
the link count in the inode. note: this assumes the
correctness assumption that (almost) all files are accessed
through the directory structure - which is not the case for
all files - the root on a volume is known only in the inode
namespace (ie, only by its inode number). other related
filesystems have other files known only by inode number as
well. in particular, those files are given a synthetic
reference count value of 1 even though they are not
referenced by directories.
when the authoritative reference count is in memory (ie
part of the running kernel computation), there are
additional references which are not reflected in the inode
which remains on-disk. these implicit additional
references distinct from the on-disk reference count are a
direct contributor to the subtleties surrounding when what
part of an in-core inode gets updated and rewritten to
disk.
another place where ref-count sharing provides very subtle
behavior is file descriptors. an offset into an open file
is stored in the file descriptor data structure, and that
structure is ref-counted and is shareable between multiple
processes (fd inheritence on fork is based on this).
this provides an important piece of shared state and is why
the >> shell operation is so trivial on Unix and so very
hard to make work on other systems which do not provide
for the simple sharing of byte offset within a file.
for instance, on VMS, one can approximate the behavior
in Unix, but it is an immense amount of hair to do so
and it is sujbect to very amusing race conditions because
the simulation cannot be made atomic without extreme pain
and performance penalties.
so my point is that if you mess too much with the reference
counting semantics, you are messing with the very heart of
Unix.
-mo
Mike O'Dell
are removing the contents, my suggestion would be to change the
"rm" command to first truncate() the file to length zero, which
*will* work if you are the owner independent of now many other
links there might be, and then have it do the unlink().
there is then a need for an "unlink" command which only does
the unlink for the cases where you want just that behaviour,
but i think the -u flag is in many versions of "rm" already
although it's traditionally useful only for the superuser
in arcane instances. this change to "rm" would make -u useful
to regular users as well.
if memory serves me, university settings where quotas are used
heavily often make this modification to "rm" so i believe there
is actual field experience with it "doing the job".
as for "real programs" which do a bucket-brigade hand-off through
a series of directories without regard for being able to
read or write the directories, YES, there are very important programs
that do this. i once built a workflow scheduler which does
*precisely* that, and the beauty is that the scheduler need have
no access to the work units being managed, only access to the
container directories used for the pipeline stages. using this
imporant instance of "least privilege" made it possible for
the scheduler to manage multiple workflow pipes while allowing
a degree of separation of the work contents which would be
impossible with the change suggested, therefore WEAKENING the
overall system security.
-mo
Mike O'Dell
of directories without regard for being able to write the FILES"
(not directories as i mistyped in the original note)
one other point - if people are also worried about
recovering file pages of "removed" files, having "rm" write
zeros (or random stuff) through them would be another thing
to add if you feel featureful.
-mo
Barry Margolin
James Hu <j...@cs.wustl.edu> wrote:
>On Sat, 16 Jan 1999 08:38:33 GMT, Barry Margolin <bar...@bbnplanet.com> wrote:
>>In article <slrn7a0hr...@jamespc.ungerhu.com>,
>>James Hu <j...@cs.wustl.edu> wrote:
>
>>>I can think of a use case. A file server is serving a deliver file
>>>request to a client. ...
>
>>Why is a hard link needed for this? Why doesn't it just mmap the named
>>file? mmap works on an open file descriptor, so it doesn't matter what
>>name was used to open it.
>
>The server may be servicing a receive file request clobbering the same
>file it is delivering.
If you're referring to NFS, the filehandle usually encodes the device and
inode number, not the filename. So it doesn't matter which link was used
to open it.
--
Tony Finch
>
>one other point - if people are also worried about recovering file
>pages of "removed" files, having "rm" write zeros (or random stuff)
>through them would be another thing to add if you feel featureful.
FreeBSD has this feature. From man rm:
-P Overwrite regular files before deleting them. Files are overwrit
ten three times, first with the byte pattern 0xff, then 0x00, and
then 0xff again, before they are deleted.
Tony.
--
f.a.n.finch d...@dotat.at fa...@demon.net
D. J. Bernstein
> "rm" command to first truncate() the file to length zero,
Inodes aren't free.
Anyway, this doesn't work for the password database. Legitimate programs
may be reading from the previous version of the database---or several
previous versions! You can't truncate a file that has to be continuously
available.
---Dan
James Hu
>In article <slrn7a0sj...@jamespc.ungerhu.com>,
>James Hu <j...@cs.wustl.edu> wrote:
>>On Sat, 16 Jan 1999 08:38:33 GMT, Barry Margolin <bar...@bbnplanet.com> wrote:
>>>In article <slrn7a0hr...@jamespc.ungerhu.com>,
>>>James Hu <j...@cs.wustl.edu> wrote:
>>
>>>>I can think of a use case. A file server is serving a deliver file
>>>>request to a client. ...
>>
>>>Why is a hard link needed for this? Why doesn't it just mmap the named
>>>file? mmap works on an open file descriptor, so it doesn't matter what
>>>name was used to open it.
>>
>>The server may be servicing a receive file request clobbering the same
>>file it is delivering.
>
>If you're referring to NFS, the filehandle usually encodes the device and
>inode number, not the filename. So it doesn't matter which link was used
>to open it.
I'm sorry, I'm not explaining myself very well. Here's the scenario I
had in mind:
t1: C1->S deliver "foo" begins
S hardlinks "foo" to "bar" and begins transfer of "bar"
t2: C2->S receive "foo" begins
S unlinks "foo", and writes out a new "foo"
t3: C1->S deliver "foo" ends
S closes "bar", notices receive "foo" is still in progress, does not
unlink "bar"
t4: C3->S deliver "foo" begins
S begins transfer of "bar"
t5: C2->S receive "foo" ends
S closes "foo"
t6: C3->S deliver "foo" ends
S closes "bar", see no pending operations on "foo", unlinks "bar"
(Scott Schwartz) Scott Schwartz
> ... I think we could probably live without hard links completely.
Plan 9 has neither hard links nor symbolic links.
Nick Maclaren
Fine. The next questions are:
1) Is it reliable (think caching and disk optimisation)?
2) Does it warn you when it isn't going to work?
If the answer to either question is "no", then it sound little more
than yet another trap for naive and unwary.
void
>
>The final part of the puzzle is that the file stays in existence until all
>links to it are gone. As noted elsewhere, your quota may be affected if the
>file hangs around, even though you believe it's gone.
This is probably a silly idea, but perhaps ownership belongs in the
directory entry rather than the inode.
--
Ben
"You have your mind on computers, it seems."
void
What does it use in their place?
void
>
>I can think of a use case. A file server is serving a deliver file
>file, them mmap's the hardlink and delivers the contents of the file
>to the client. After finishing, the server unlinks. If a user on the
>server machine modifies the original file while delivery is in
>progress, it does not corrupt the mmap'd copy that is in transit.
I think that would only work if the mmap were done with the MAP_PRIVATE
flag.
Nick Maclaren
void <fl...@interport.net> wrote:
>On Fri, 15 Jan 1999 19:00:11 GMT, Alun Jones <al...@texis.com> wrote:
>>
>>The final part of the puzzle is that the file stays in existence until all
>>links to it are gone. As noted elsewhere, your quota may be affected if the
>>file hangs around, even though you believe it's gone.
>
>This is probably a silly idea, but perhaps ownership belongs in the
>directory entry rather than the inode.
It's not a silly idea - it's a very good one. It's just not Unix.
Kurt Hockenbury
: Indeed, hard linkability should probably be the same as chmodability
: and chgrpability.
: (As a side note it also lets people change the ctime of files - which
: suggests that it should probably be the same class of thing as chmoding).
If you have the source to your OS, this should be an easy change. For
instance, in Linux 2.0.x, it looks to be to be in
/usr/src/linux/fs/namei.c. A tiny patch can make it that hard links
work only for root and the file owner.
WARNING: I am not a kernel hacker by any stretch of the imagination.
Heck, I haven't even written a large C program in years. I think this
patch does what I want (I tested it on my own system), but it may wipe
your disk, set fire to your dog, or any number of other unknown bad
things. Use at your own risk.
--- namei.c.orig Mon Jan 18 00:34:27 1999
+++ namei.c Mon Jan 18 00:40:43 1999
@@ -802,6 +802,12 @@
iput(oldinode);
return error;
}
+ /*
+ * Only allow a hard link to be made for the file owner or root.
+ */
+ if ((current->fsuid != oldinode->i_uid) && (current->fsuid != 0)) {
+ return -EACCES;
+ }
/*
* A link to an append-only or immutable file cannot be created
*/
The link(2) manpage on such a patched system should be updated to reflect
this change.
I don't think this change would break very much in practice, though it
probably breaks POSIX compliance.
-Kurt
Wilhelm B. Kloke
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>In article <slrn7a4rob...@interport.net>,
>void <fl...@interport.net> wrote:
>>On Fri, 15 Jan 1999 19:00:11 GMT, Alun Jones <al...@texis.com> wrote:
>>>
>>>The final part of the puzzle is that the file stays in existence until all
>>>links to it are gone. As noted elsewhere, your quota may be affected if the
>>>file hangs around, even though you believe it's gone.
>>
>>This is probably a silly idea, but perhaps ownership belongs in the
>>directory entry rather than the inode.
>
>It's not a silly idea - it's a very good one. It's just not Unix.
It cannot be a good one on Unix, for the set[ug]id bits e.g..
Also for quota.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 montags und dienstags
Barry Margolin
Wilhelm B. Kloke <w...@yorikke.arb-phys.uni-dortmund.de> wrote:
>In article <77u3sn$81m$1...@pegasus.csx.cam.ac.uk>,
>Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>>In article <slrn7a4rob...@interport.net>,
>>void <fl...@interport.net> wrote:
>>>On Fri, 15 Jan 1999 19:00:11 GMT, Alun Jones <al...@texis.com> wrote:
>>>>
>>>>The final part of the puzzle is that the file stays in existence until all
>>>>links to it are gone. As noted elsewhere, your quota may be affected if the
>>>>file hangs around, even though you believe it's gone.
>>>
>>>This is probably a silly idea, but perhaps ownership belongs in the
>>>directory entry rather than the inode.
>>
>>It's not a silly idea - it's a very good one. It's just not Unix.
>
>It cannot be a good one on Unix, for the set[ug]id bits e.g..
And chmod.
>Also for quota.
I think quota was what he was trying to solve, i.e. the disk space would be
charged to you because you own the directory entry. This sounds like a
variant of the suggestion a couple of weeks ago that deleting the original
link should cause the ownership to change, so that the original owner
wouldn't continue to be charged for a file he thought he got rid of.
Bruno Wolff III
>
> I think quota was what he was trying to solve, i.e. the disk space would be
> charged to you because you own the directory entry. This sounds like a
> variant of the suggestion a couple of weeks ago that deleting the original
> link should cause the ownership to change, so that the original owner
> wouldn't continue to be charged for a file he thought he got rid of.
I don't think changing the ownership of a file on deletion is a good idea.
If the file is supposed to be private you still don't want to delete it
while other people have links to it.
I think the only allowing hard links by the owner and root suggestion was
a reasonable idea.
Casey Schaufler
> This is probably a silly idea, but perhaps ownership belongs in the
> directory entry rather than the inode.
It's been suggested, and many people assume that that's the way
it works. From a security modeling viewpoint, adding attribute
information (ownership, mode bits, ...) to the directory entry
would be a real problem. Once you do that, you have a real tough
time describing what a directory entry is. With the existing scheme,
a directory entry is just data in the directory, and access is
controlled based on the attributes of the directory. If you add
ownership to the entry, the security semanitic for chown gets
complex, as you're not only changing the attributes of the
file, but the contents of one or more (hard links!) directories.
Furthermore, chown would now require you have write access to
all containing directories.
Yuk.
--
Casey Schaufler voice: (650) 933-1634
ca...@sgi.com fax: (650) 933-0513
scha...@dockmaster2.ncsc.mil
Geoffrey KEATING
> On Fri, 15 Jan 1999 19:00:11 GMT, Alun Jones <al...@texis.com> wrote:
> >
> >The final part of the puzzle is that the file stays in existence until all
> >links to it are gone. As noted elsewhere, your quota may be affected if the
> >file hangs around, even though you believe it's gone.
>
> This is probably a silly idea, but perhaps ownership belongs in the
> directory entry rather than the inode.
That might make it a bit tricky to revoke access to a file. No doubt
it would also cause, or aggravate, a lot of /tmp security holes.
I've always thought the best solution to the problem is to make the
file zero-length before deleting it. Or have a proper disk space
accounting system that isn't tied to file permissions.
--
Geoff Keating <Geoff....@anu.edu.au>
Nick Maclaren
In article <ymKo2.309$oD6....@burlma1-snr1.gtei.net>, Barry Margolin <bar...@bbnplanet.com> writes:
|>
|> I think quota was what he was trying to solve, i.e. the disk space would be
|> charged to you because you own the directory entry. This sounds like a
|> variant of the suggestion a couple of weeks ago that deleting the original
|> link should cause the ownership to change, so that the original owner
|> wouldn't continue to be charged for a file he thought he got rid of.
That's what it seems to me. In case anyone is interested, here is a
solution to the problem but - be warned - it is not Unix!
All inode information is held in a directory, and all files and
directories created by ordinary users have the ownership of their
parent directory. A file has precisely one one parent, just as
directories now do (usually.)
A file or directory tree (and I do mean tree) can be moved between
directories with the same ownership and (modulo authorities) between
ones with different ownerships. In unprivileged cases, that implies
changing ownership, with all that it implies.
Symbolic links are as normal. Hard ones are held in reverse (i.e.
a chain starting from the file), and are updated whenever there is
a change to the ownership or permissions of a file or a parent
directory. And, yes, they go away when a file does.
This has a lot of administrative and security advantages, at the
expense of making certain (relatively rare) actions expensive.
But it is philosophically about as far from Unix as it is possible
to get, while still using the same directory/file/link/permission
design :-)
I don't believe that minor tweaks to Unix will help much.
Matthew Whelan
> <snip>
> If you add
> ownership to the entry, the security semanitic for chown gets
> complex, as you're not only changing the attributes of the
> file, but the contents of one or more (hard links!) directories.
> Furthermore, chown would now require you have write access to
> all containing directories.
>
My take on what was suggested was that each of the hard links was
differently owned (which makes control of permissions an interesting
issue) and when the 'first' entry to it is deleted, the space is
accounted to the 'next' user in the chain. Thus directory entries don't
have to be changed (except for the one being removed). This is clearly
more and more hideous the more you think about the permissions problem.
Also, it allows a way for ownership of files to be passed around,
admittedly needing the consent of both parties.
Which brings me to my other point - chown nowadays is restricted to the
superuser, since it's not a good idea to allow users to give away
ownership of their files for quota and other reasons - so writeability
to the directories shouldn't be a problem anyway for chown, if I'm wrong
about the model proposed
~ Matthew ~
Casey Schaufler
> chown nowadays is restricted to the
> superuser, since it's not a good idea to allow users to give away
> ownership of their files for quota and other reasons - so writeability
> to the directories shouldn't be a problem anyway for chown, if I'm wrong
> about the model proposed
Once the directory entry expands beyond the name/inode pair
it tends to get everything dumped into it, lest stat(2) become
an unholy mess. At that point, all issues mentioned regarding
chown apply to chmod, utime, etc.
The one thing I didn't see mentioned (but I'm old and slow, so
I may have just missed it) was keeping the directory entries in
sync. If that doesn't happen, your security story is a bad
graphic novel.
(Scott Schwartz) Scott Schwartz
> >Barry Margolin <bar...@bbnplanet.com> writes:
> >> ... I think we could probably live without hard links completely.
> >
> >Plan 9 has neither hard links nor symbolic links.
>
> What does it use in their place?
Nothing equivalent, really. Like Barry said, you can live without
them. Plan 9 has per-process namespaces and union mounts, so you can
alter your view of the filesystem on an ad-hoc basis, but the style of
the system is different than unix.
Bill Vermillion
Barry Margolin <bar...@bbnplanet.com> wrote:
>In article <77ove0$rtg$1...@neserve0.uu.net>, Mike O'Dell <m...@uunet.uu.net> wrote:
>>Unix without soft links is much more painful, but Unix without
>>hard links is unworkable.
>I disagree. While the open file reference count feature is quite
>nice, the need for multiple directory entries pointing to the
>same inode is hardly critical. The OS currently makes use of the
>same underlying mechanism (the reference count in the in-core
>inode), this is not really necessary. It's already the case that
>the in-core inode's reference count is different than the on-disk
>inode's reference count when the file is open (so that fsck will
>know that it's safe to get rid of a file if the system crashes
>while a deleted file was open). If the disk inode didn't have a
>reference count, the memory inode reference count could still have
>this, to support deleting open files.
I have a question about this. If you have a program that ooperates
differently depending on the name by which it is called and is hard
linked to these names, will it act the same as symlinks in this
case. Will it see the name from the symlink as the argv[] thingy?
I had assumed that these needed hardlinks for the above name
passing.
--
Bill Vermillion bv @ wjv.com
Barry Margolin
Bill Vermillion <bi...@bilver.magicnet.netREMOVETHIS> wrote:
>I have a question about this. If you have a program that ooperates
>differently depending on the name by which it is called and is hard
>linked to these names, will it act the same as symlinks in this
>case. Will it see the name from the symlink as the argv[] thingy?
It sees whatever was provided as argv[0] in the exec() call. When the
command is invoked from the shell, that's whatever the first word of the
command line was (after alias expansion and variable/backtick
substitutions).
>I had assumed that these needed hardlinks for the above name
>passing.
Symlinks will work just as well.