[Clipart] Two issues

[Jonadab the Unsightly One]

Jon Phillips <jon at rejon.org> writes:

> Jonadab the Unsightly One wrote:

>> Incidentally, another minor wrinkle:  since the mv of incoming to
>> incoming-pre-0.09 no new files have been submitted, either because
>> nobody has tried, or because the new incoming dir that I created
>> has incorrect permissions.  I attempted to make its permissions
>> match those of the other directory, but they don't quite:

>> drwsrwsr-x  2 jonadab clipart 4096 Dec 30 15:08 /srv/clipart.freedesktop.org/clipart_web/incoming
>> drwxrwxr-x+ 2 bryce   clipart 4096 Dec 29 22:21 /srv/clipart.freedesktop.org/clipart_web/incoming-pre-0.09

> Yeah, test out a dummy svg and see what happens. 

Oh, dear.  My worries are confirmed.  The uploaded file disappeared
into thin air...

> I think you need to get the incoming folder to have write access
> from sitewranglers. You should file a bug on
> bugzilla.freedesktop.org if you can't change it back to writable
> with the plus.

The thing is, I *thought* I understood Unix filesystem permissions,
but that plus symbol has me baffled; I have NO idea what it even
means.

I have worked around the problem temporarily by giving that directory
world write permissions, which seems to work now, but this is not the
way the incoming directory was set up before and is probably less
secure (although _off the top of my head_ I cannot think of any way it
could be exploited...), which we don't want.  I'll have to do some
more reading on filesystem permissions and see if I can figure out
what that + means.  I don't want to bug sitewranglers yet again unless
I don't think we can fix it without them.  If I can't figure it out in
a day or so, I'll file it in bugzilla.

> I had problems with this previously. Maybe a better approach is to
> mv incoming/* to a new folder that has the incoming-0.09 and just
> keep incoming alone.

I didn't have permissions to move incoming/* to anywhere.

> Now, fd.o is pushing stronger security and I don't blame em.

No, I don't blame them for that, under the circumstances.  I'm just
not accustomed to this sort of thing, because I've never previously
had an account on a system I didn't personally have admin privs on,
and for that matter I've never previously had an account on a *nix
system I didn't personally install.  At home, I build my own systems
of course, and at work I am The Computer Guy, with the rest of the
staff having their expertise in another field entirely.  So this is
actually very good experience for me to have (although it can be
frustrating at times, getting "you don't have permission to do that"
errors, which never happens to me at home).

I'm not completely unfamiliar with permissions issues, because I do
administer a small CGI server at work, but with that I've only run
into a small subset of the potential wrinkles, because in that
situation setting up the permissions so that Apache can and can't do
what I do and don't want it to be able to do has no impact on what *I*
can and can't do.  On freedesktop.org we have interactions between how
the permissions impact the CGI scripts and the web server versus how
they impact user accounts in the clipart group, and that's really a
whole new class of issues that I've never experienced before.  An
opportunity to learn something, I suppose.

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/