Subject: [netatalk-admins] Feature Suggestion: AFP/TCP running as user, not root

From: Eugene Cohen <[email-masked]>
Date: Thu, 13 Nov 1997 09:50:10 -0600

As AFP 2.2 compliance (which adds TCP/IP support) starts getting folded
into netatalk, there should not be the necessity for afpd to run as root.
In the "old days" AppleTalk was the only transport, so the daemons had to
run as root to access the raw network hardware.

It should be possible now, if afpd is able run only supporting TCP/IP
connections, to have the daemon run as something other than root.  The only
change that would need to be made would be support for perhaps a custom
passwd file since many systems now support shadow authentication and only
the root account can read the shadow file.  Is the addition of the ability
to run as a non-root user feasible given the source base?

-Eugene

---

From: Stefan Bethke <[email-masked]>
Date: Thu, 13 Nov 1997 18:09:14 +0100

>run as root to access the raw network hardware.

The limitation in socket(2) should be fairly easy to remove. I would
believe it only got in there because you need root credentials to get a raw
IP socket, so the netatalk team copied that.

>to run as a non-root user feasible given the source base?

Probably not: for the child apfd to become the effective (logged-in) user,
the master afpd must have appropiate privileges, and that usually means uid
0.

What is your objection against running the master afpd as root, besides the
usual wisdom of running as few as possible processes as root?

Stefan

--
Stefan Bethke
Promo Datentechnik      |  Tel. +49-40-851744-18
+ Systemberatung GmbH   |  Fax. +49-40-851744-44
Eduardstrasse 46-48     |  e-mail: [email-masked]
D-20257 Hamburg         |  http://www.Promo.DE/

---

From: Eugene Cohen <[email-masked]>
Date: Thu, 13 Nov 1997 11:50:51 -0600

What I'm thinking of is the situation where a user, not an administrator,
would like to mount the server on his Mac with the priviledges that his
account on the server has.  I'm envisioning an authentication scheme where
the [AFP] logged in user keeps the UID of afpd.  Under this scheme, a
single (non-root) user could start the specially-configured afpd running on
a high port number, and log in and access the server with the priviledges
that their account on the server already has.  In other words, the
authentcation mechansim would not change the UID, but rather allow a single
account (that of the user running afpd) access to the server.

What I would like to do is to write a simple program on my Mac that would
send an rsh command to a server to start afpd, log in and mount the volume,
and later send another rsh command to stop afpd once I have logged out.
(The sysadmins usually don't like us to keep daemon processes running all
the time).  I think this could be valuable to users out there.  See what
I'm getting at?  Would this be too difficult to implement?

-Eugene

---

From: Mark Donnelly <[email-masked]>
Date: Thu, 13 Nov 1997 18:09:24 -0600

<snip!>

>Under this scheme, a
<snip! again>
>-Eugene

Well, I, for one, see at least one problem with this.  As far as I can tell,
there is only one port that a Macintosh client will try to connect to.  So,
again under this scheme, only one person would be allowed to use this at a time.
That would be fairly rood if anyone else would like to try the same thing.

It sounds like the BEST solution will be to have the system administrators run
the daemon.  However, if that isn't a possibility, I definately see some merit
in your approach.

--Mark
   "I think so Brain, but if they called them sad meals, then 
    no one would buy them."

---

From: Aaron Gowatch <[email-masked]>
Date: Thu, 13 Nov 1997 16:10:35 -0800 (PST)

On Thu, 13 Nov 1997, Eugene Cohen wrote:

> account on the server has.  

This already happens with Netatalk, which is why the afpd child runs as
the user that has logged in.

> I'm envisioning an authentication scheme where the [AFP] logged in user
> keeps the UID of afpd.  Under this scheme, a single (non-root) user
> could start the specially-configured afpd running on a high port number,
> and log in and access the server with the priviledges that their account
> on the server already has.  In other words, the authentcation mechansim
> would not change the UID, but rather allow a single account (that of the
> user running afpd) access to the server. 

The parent afpd, which runs as root, forks a child process which runs as
the user that is logging in.  This child process has the same privileges
as that of a user logged into their shell account.

How will you get your Appletalk client to use this arbitrary port that you
start afpd on?  This requires more than a modification to the Netatalk
sources, namely the source for the Appletalk client.  The issues
surrounding running multiple processes that try to use the same port are
obvious...

But honestly, this is a rather silly idea.  Its a lot like saying "I dont
want named running as root on my system, so everytime I need to lookup a
name, I'll have the TCP stack rsh to my configured DNS host, startup
named, I'll perform my query, have the TCP stack rsh my DNS host again and
shutdown named.  I'll do this everytime I want to perform a DNS lookup,
and it will be better".

Even if you *could* get it to work, the overhead saved is so minimal, its
not even worth the effort to try to make it work, not to mention how slow
it would be. For instance, if 10 users we're logged into your Netatalk
box, there would be ~11 afpd processes.  With the "rsh n' start"
mechanism, there would be 10, only the process which runs as root would be
missing. 

Aa.

---

From: Stefan Bethke <[email-masked]>
Date: Fri, 14 Nov 1997 11:53:36 +0100

>>usual wisdom of running as few as possible processes as root?

So what you want is cheat on your sysops :-)

I think this could be done, but it might involve some serious code changes,
and for me this isn't worthwile.

Stefan

---

From: Stefan Bethke <[email-masked]>
Date: Fri, 14 Nov 1997 12:42:40 +0100

>again under this scheme, only one person would be allowed to use this at a

In the "Server IP Adress" dialog, enter host.do.main:1234 to connect to
port 1234.

Stefan

---

From: Eugene Cohen <[email-masked]>
Date: Fri, 14 Nov 1997 08:59:28 -0600

>mechanism, there would be 10, only the process which runs as root would be

I didn't think it was a silly idea.  I don't want to run the daemon to
server all the users of the system, I just want to bring it up OCCASIONALLY
when I want to mount the server on *my* Mac with *my* account's permissions
and nothing more.  I am a user of the system, and do not have root access,
but the sysadmins don't have the time or knowhow to install netatalk, and
they would not mind if I  ran it myself (if it was possible - this is what
we're dicussing) occasionally.  It isn't fair to compare what I am
proposing to be used with named.  That's not the purpose of what I'm
saying.  I don't want to save CPU necessarily, I just want non-root users
to be able to run it.  You dig?

-Eugene

---

From: Eugene Cohen <[email-masked]>
Date: Fri, 14 Nov 1997 09:00:35 -0600

>and for me this isn't worthwile.

I know my "sysops" won't mind if I don't keep the daemon running all the time.

If I had time, I'd try to make the changes to the sources myself.  Maybe
someday I'll actually have the time.

-Eugene

---

From: a sun <[email-masked]>
Date: Fri, 14 Nov 1997 11:08:25 -0800 (PST)

well, if people are really that interested in doing such a thing, it's
fairly trivial to do. contrary to popular belief, the appletalk stuff
should work almost without change. you're not using anything reserved
there. the afp/tcp stuff needs to use a different port as the reserved
port is root accessible only.

so, *IF* you really want to do this and thereby open your account to
who knows what, here's what you need to do:
	1) edit auth.c and comment out the setgid/setuid calls. 

	2) realize that this will cause everything to be accessed as
	   you. i.e., if you don't want someone else to use their
	   password to access your stuff, you're going to have to edit
	   auth.c again and make sure you actually check that the
	   requesting password corresponds to the uid of the afpd
	   process.

	3) run with a different port, lock file, and AppleVolumes.*
	   files. 

	4) caveat emptor

once again, this matter is *completely* separate from afp/tcp
vs. afp/ddp. 

-a

---

From: a sun <[email-masked]>
Date: Fri, 14 Nov 1997 11:15:04 -0800 (PST)

erk. i just realized that for the machines without appletalk built-in
or already loaded, you'll have to disable that part from afpd. 

-a

---

From: Eugene Cohen <[email-masked]>
Date: Fri, 14 Nov 1997 15:08:31 -0600

>or already loaded, you'll have to disable that part from afpd.

You mean running with the noddp switch isn't enough?  So afpd currently
needs to talk to the ddp implementation even if it's running over tcp only?

The other thing that I alluded to earlier is that, unless I'm mistaken and
that is quite possible, if the server is running a shadowed password
system, then only the root account can authenticate users using the host's
password files.  Or am I mistaken in that there is some system call that
can authenticate a user without actually revealing the encrypted password?

This is why I thought there would have to be some code modification to
support a different password file, or perhaps a single password (since this
implementation would only be used by a single user).  This wouldn't be too
difficult to hack, I think.

-Eugene

---

From: a sun <[email-masked]>
Date: Fri, 14 Nov 1997 13:12:32 -0800 (PST)

-noddp is enough.

if the server is using shadow passwords, there's always ~/.passwd and
using the 2-way randnum uam.

-a

---

From: Aaron Gowatch <[email-masked]>
Date: Fri, 14 Nov 1997 13:59:58 -0800 (PST)

> using the 2-way randnum uam.

Wont this essentially revoke any privileges the user would have under
normal circumstances?  If not, though I believe it will, it would
constitute a very serious security hole.  What would stop a user from
creating a passwd file that has a root entry with say, no passwd, then
using that passwd file to authenticate himself as root?  Short of
rewriting getpwnam(), setuid(), setgid() and friends, I dont think it can
be done.

Aa.

---

From: a sun <[email-masked]>
Date: Fri, 14 Nov 1997 14:13:41 -0800 (PST)

um, man setuid()/setgid() would be called for here. unless you're
root, you can't change your identity. the only hole can you open up is
allowing others to access your appleshare volume as you.

-a

---

From: Aaron Gowatch <[email-masked]>
Date: Fri, 14 Nov 1997 14:23:23 -0800 (PST)

> allowing others to access your appleshare volume as you.

So maybe including setuid() and setgid() with the rest was probably going
too far.  Yes, after I sent the message I decided that if you ripped all
of the auth stuff out, started afpd as yourself, you could in theory
connect to the box with whatever permissions the process has.

Finding out what port a user is running their afpd on could be as simple
as running netstat -a.

As a Sysadmin, security is an obvious concern.  I'm glad that no one is
trying to do this on one of our machines.

Aa.

---

From: [email-masked]
Date: Fri, 14 Nov 1997 18:42:09 -0500

afpd doesn't, does not need to, run setuid root.  And on most systems,
it's not an error to setuid your current uid.  When I'm debugging afpd,
I often run it as myself.  The number of glitches is really small.
Like, afp/tcp needs a reserved port (someone mentioned the
work-around), quotas probably won't work, the password file might be
shadows.

:wes

---

From: a sun <[email-masked]>
Date: Fri, 14 Nov 1997 15:56:58 -0800 (PST)

my mistake. it's actually initgroups() that complains for me.

-a

---

From: Bill Studenmund <[email-masked]>
Date: Fri, 14 Nov 1997 16:17:59 -0800 (PST)

On Fri, 14 Nov 1997, Aaron Gowatch wrote:

[user-started afpd's]

> trying to do this on one of our machines.

What is the concern? The afpd in question can not do anything the user
can't do. In some ways, it can do less than a user at a command line (afpd
AFAIK can't call arbitrary shell commands, so it can't get at buffer
overruns).

All such an afpd could do is what an ftp process run as the user could do.
It could fill up partitions (either to quota or free space limits) which
are writable by the user, or show files which are readable by the user.

If the user would be ftp'ing in to get and store these files, I don't see
how this is _less_ secure than ftp. Unless of course you have a kerberized
ftp and compare it against plain-text password authentication on afpd.

Take care,

Bill