[RESEND] [PATCH] Add apr_uid_shell_get

[Andrew Stribblehill <a....@durham.ac.uk>]

I'm trying to improve httpd's mod_userdir so that it knows it
shouldn't serve ~fool when user 'fool' has an administratively
prohibited shell, so:

UserDir DisableShell /bin/badlad

To this end, I need a function to query the user's shell. It seems
sensible to me (though I am new to apr) that it should go into apr.

I've written a patch that does this; it's attached.

What do you think?

-- 
HEBRIDES
VARIABLE 3 OR LESS BECOMING SOUTHEASTERLY 4 OR 5. RAIN OR DRIZZLE.
MODERATE OR GOOD

Re: [RESEND] [PATCH] Add apr_uid_shell_get

[Andrew Stribblehill <a....@durham.ac.uk>]

Quoting Cliff Woolley <jw...@virginia.edu> (2004-08-04 00:14:28 BST):
> On Tue, 3 Aug 2004, Andrew Stribblehill wrote:

<snip justification and usage case>

> > To this end, I need a function to query the user's shell. It seems
> > sensible to me (though I am new to apr) that it should go into apr.
> 
> The problem is that there's no portable concept of a shell, right?  I
> mean, users on Windows all get the same shell (or at least there's no
> shell associated with their uid as such), and certainly this wouldn't
> apply to netware... how would those platforms be handled, besides
> returning APR_ENOTIMPL?  I don't think they can be.  Typically our policy
> in APR has been that we provide the lowest common denominator of
> functionality... if a concept doesn't map onto anything but unix, we would
> tend to be hesitant to make it part of APR.  That's not to say there are
> no non-portable things in APR, but they're all stuffed away in apr_os_*...
> I guess maybe if this were apr_os_shell_get() I'd be more willing to
> consider it.  :)

That's true. I'm very new to APR so I didn't quite see it. If it were
apr_os_shell_get(), would a Windows APR return APR_ENOTIMPL or would
the function just not exist?

-- 
FISHER
NORTHEASTERLY 4 OR 5 BECOMING VARIABLE 3. OCCASIONAL RAIN. MODERATE

Re: [RESEND] [PATCH] Add apr_uid_shell_get

[Cliff Woolley <jw...@virginia.edu>]

On Tue, 3 Aug 2004, Andrew Stribblehill wrote:

> I'm trying to improve httpd's mod_userdir so that it knows it
> shouldn't serve ~fool when user 'fool' has an administratively
> prohibited shell, so:
>
> UserDir DisableShell /bin/badlad
>
> To this end, I need a function to query the user's shell. It seems
> sensible to me (though I am new to apr) that it should go into apr.

The problem is that there's no portable concept of a shell, right?  I
mean, users on Windows all get the same shell (or at least there's no
shell associated with their uid as such), and certainly this wouldn't
apply to netware... how would those platforms be handled, besides
returning APR_ENOTIMPL?  I don't think they can be.  Typically our policy
in APR has been that we provide the lowest common denominator of
functionality... if a concept doesn't map onto anything but unix, we would
tend to be hesitant to make it part of APR.  That's not to say there are
no non-portable things in APR, but they're all stuffed away in apr_os_*...
I guess maybe if this were apr_os_shell_get() I'd be more willing to
consider it.  :)