[Proftpd-user] Problem applying group permissions

[John Kortink]

It seems that ProFTPD (1.3.5) has bugs regarding the application of group ownership / permissions.


We have a number of users that exist outside Unix, which are mapped by our ProFTPd extension module to two ordinary Unix users, each within their own separate uid and gid, that cannot login. When ProFTPd spawns a process for either of those users, they run with the correct uid and gid.


We then tested whether or not either user can 'get' files owned by the four combinations of either (one as user, one as group), and with all combinations of permissions. This points out that the rules regarding the user owner are applied correctly (even though a 'cd' to a directory which should be refused according to these rules is always allowed), but that the rules regarding the group owner are not. It seems that in certain cases, both users are considered to be in the same group, and are allowed access, even though they are completely seperate (both in user and group).


If someone can shed some light on this, we would appreciate it.


________________________________

This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.

[TJ Saunders]

> We have a number of users that exist outside Unix, which are mapped by
> our ProFTPd extension module to two ordinary Unix users, each within
> their own separate uid and gid, that cannot login. When ProFTPd spawns a
> process for either of those users, they run with the correct uid and gid.
>
> We then tested whether or not either user can 'get' files owned by the
> four combinations of either (one as user, one as group), and with all
> combinations of permissions. This points out that the rules regarding the
> user owner are applied correctly (even though a 'cd' to a directory which
> should be refused according to these rules is always allowed),

You have not mentioned the permissions (read, write, execute) that the
files/directories have; this information is necessary to truly decide
whether a "change directory" operation would normally be allowed or not.

> but that the rules regarding the group owner are not. It seems that in certain
> cases, both users are considered to be in the same group, and are allowed
> access, even though they are completely seperate (both in user and
> group).

What are these "certain cases", specifically? If, for example, the
files are world-readable, it won't matter which users/groups own the
files; they could still be read by any user.

Thus, in order to help determine what may be happening, we need to know
more specific information about the permissions and ownership of the
files/directories in question.

Cheers,
TJ

[John Kortink]

I'm not asking for my conclusions to be second guessed. I know exactly how Unix permissions and ownership work. There is an actual problem.

Something very strange is going on. I debugged it down to the bare metal, where the proftpd code does an open() call on the file, and it is very simple : it is allowed inside proftpd, it is disallowed outside (with a bit of independent C code). This is with the exact same path, chroot, UID, GID, EUID, EGID, even SUID, SGID. As far as I know, there are no other factors that determine access, except for things like SELinux, but there is no security context associated with the test file.

We use our own mapping of a large user base to two Unix users (via an adaptation of the sftp module). We eventually 'solved' (probably circumvented is a better term) by renaming one of these Unix users to a username not in our user base, and it worked. It seems somewhere in proftpd something gets confused about user A (our own user) logging in, and it being mapped by our plugin module to user A (the Unix user, i.e. with the same name). If these names are different, the problem no longer occurs.


John Kortink

________________________________________
From: TJ Saunders <***@castaglia.org>
Sent: 08 October 2015 07:22
To: proftp-***@lists.sourceforge.net
Subject: Re: [Proftpd-user] Problem applying group permissions

> We have a number of users that exist outside Unix, which are mapped by
> our ProFTPd extension module to two ordinary Unix users, each within
> their own separate uid and gid, that cannot login. When ProFTPd spawns a
> process for either of those users, they run with the correct uid and gid.
>
> We then tested whether or not either user can 'get' files owned by the
> four combinations of either (one as user, one as group), and with all
> combinations of permissions. This points out that the rules regarding the
> user owner are applied correctly (even though a 'cd' to a directory which
> should be refused according to these rules is always allowed),

You have not mentioned the permissions (read, write, execute) that the
files/directories have; this information is necessary to truly decide
whether a "change directory" operation would normally be allowed or not.

> but that the rules regarding the group owner are not. It seems that in certain
> cases, both users are considered to be in the same group, and are allowed
> access, even though they are completely seperate (both in user and
> group).

What are these "certain cases", specifically? If, for example, the
files are world-readable, it won't matter which users/groups own the
files; they could still be read by any user.

Thus, in order to help determine what may be happening, we need to know
more specific information about the permissions and ownership of the
files/directories in question.

Cheers,
TJ

------------------------------------------------------------------------------
_______________________________________________
ProFTPD Users List <proftpd-***@proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

________________________________

This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.

[TJ Saunders]

> I'm not asking for my conclusions to be second guessed.

No, but since you did not provide enough information, anything we could
do to help would, by necessity, be speculation, and would have to
involve second guessing. For instance, the fact that you are running
custom code was not something you mentioned, and that sort of thing can
have unexpected side effects/impacts.

> I know exactly how Unix permissions and ownership work. There is an actual problem.

I believe you, but to get to the root of the problem, you might try
being less combative with your responses. I am trying to help, and am
not looking for an argument. Attitudes like the above, though, make me
feel that my attempts to help are not actually wanted in this case.

> Something very strange is going on. I debugged it down to the bare metal,
> where the proftpd code does an open() call on the file, and it is very
> simple : it is allowed inside proftpd, it is disallowed outside (with a
> bit of independent C code). This is with the exact same path, chroot,
> UID, GID, EUID, EGID, even SUID, SGID. As far as I know, there are no
> other factors that determine access, except for things like SELinux, but
> there is no security context associated with the test file.

Another possible factor is the use of POSIX ACLs. Are you possibly
using a kernel, and filesystem, that have POSIX ACL support? And using
a proftpd compiled with the --enable-facl configure option?

TJ

[John Kortink]

>> I'm not asking for my conclusions to be second guessed.
>
>No, but since you did not provide enough information, anything we could
>do to help would, by necessity, be speculation, and would have to
>involve second guessing. For instance, the fact that you are running
>custom code was not something you mentioned, and that sort of thing can
>have unexpected side effects/impacts.

Hardly, since all we do is return a Unix user record for 'our' user, and then onwards, proftpd will simply run as that user / group in a process with a chroot jail.

>> I know exactly how Unix permissions and ownership work. There is an actual problem.
>
>I believe you, but to get to the root of the problem, you might try
>being less combative with your responses. I am trying to help, and am
>not looking for an argument. Attitudes like the above, though, make me
>feel that my attempts to help are not actually wanted in this case.

Nevertheless, among developers, it's a waste of time to ask 'have you plugged it in' type of questions.

I have now summarized the situation concisely.

>> Something very strange is going on. I debugged it down to the bare metal,
>> where the proftpd code does an open() call on the file, and it is very
>> simple : it is allowed inside proftpd, it is disallowed outside (with a
>> bit of independent C code). This is with the exact same path, chroot,
>> UID, GID, EUID, EGID, even SUID, SGID. As far as I know, there are no
>> other factors that determine access, except for things like SELinux, but
>> there is no security context associated with the test file.
>
>Another possible factor is the use of POSIX ACLs. Are you possibly
>using a kernel, and filesystem, that have POSIX ACL support? And using
>a proftpd compiled with the --enable-facl configure option?

Yes, and yes. But there no ACL is attached to anything in this case.

I'll be even more concise : I'm simply looking for that one possible reason why someone running with the exact same IDs has access to a particular file (as determined exactly at the relevant open() call) inside proftpd, and not outside.


John Kortink


________________________________

This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.

[John Kortink]

>What are these "certain cases", specifically? If, for example, the
>files are world-readable, it won't matter which users/groups own the
>files; they could still be read by any user.

That is not true for a start, by the way. If you are user X and own a r-xrwxrwx file, you will be the only one not able to write. Unix will first check which class you belong to (user, group, world, in that order). Then the permission bits for that class apply. It is a misconception that if a file is world accessible, it is therefore accessible by everyone.


John Kortink


________________________________

This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.