Re: chgrp with user

[Nicolas George]

Le tridi 3 nivôse, an CCXXV, Xen a écrit :
> I think my point was more that I didn't know how to chgrp, but I found I
> needed to add myself to www-data first before I could chgrp to it.

Just a basic sanity check:

If your web server is running as www-data, then it is better if the
files do NOT belong to that user and/or group. For the group, it does
not matter much, but for the user it is very important.

Most importantly, the web server must not have write access to the files
it serves.

Some web applications need write access, of course, but they should get
write access ONLY to the files and directories they need, NEVER the
program files. And the web server must be configured to never execute
anything from these directories, if they are served.

For example, if your application is making photo albums, it needs write
access to the directory where it stores the photos, but only that, and
all ScriptAlias or equivalent must be disabled for that directory.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: chgrp with user

[Greg Wooledge]

On Fri, Dec 23, 2016 at 01:17:23AM +0100, Xen wrote:
> Life becomes a whole lot easier if you can do stuff with your regular 
> user, which is why I am putting stuff in my user home directory in the 
> first place, instead of some central location.

Making your life easier should NOT be your #1 priority when talking
about a public web server, especially if PHP is involved in any way.
Security should be at least somewhere near the top of the list.

You want to minimize the damage that an attacker can do when (not if)
your Apache+PHP stack gets compromised by yet another PHP vulnerability.

Re: chgrp with user

[Andy Smith]

Hi Xen,

On Thu, Dec 22, 2016 at 06:24:59PM +0100, Xen wrote:
> I am trying to get a webserver to run under my regular user, or at
> least to have the website's files under control of my regular user,
> but the webserver runs as www-data.

You've been shown how to put yourself in the www-data group so that
you can make the files group-writable and still edit them with your
normal user.

Other solutions include:

- Run a separate web server on a high port, so that it can listen on
  this port without needing special privileges. Proxy to this server
  from your main web server that listens on port 80. In this way the
  main web server does not need PHP and touches no files, it just
  listens on port 80 and proxies connections. The other web server
  runs as an unprivileged user and reads the files.

- If using apache, you can make each vhost run as a different
  unprivileged user with a different MPM such as apache2-mpm-itk.
  Other web servers may have similar features.

- You could run PHP under FastCGI which would let you potentially
  run each site's FastCGI server as a different user. Although this
  would mean that every page would have to come through FastCGI
  with no opportunity for simple static file serving.

  Here's an example of php-fpm under nginx on jessie:

  
https://www.howtoforge.com/tutorial/installing-nginx-with-php-fpm-and-mariadb-lemp-on-debian-jessie/

  That example doesn't show how to have different users. This one
  does; it is for Ubuntu but you can pretty easily get the idea:

  
https://www.digitalocean.com/community/tutorials/how-to-host-multiple-websites-securely-with-nginx-and-php-fpm-on-ubuntu-14-04

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Preventing ACL on cdrom drive...

[Nimrod]

Hi, 

sorry for this trivial question, but I really tried to find an answer on
the web without any result.

This is the issue: on a computer at home (shared among relatives, each
with his/her own account), the first user that logs in after boot locks
the cdrom drive, and any other user that logs in can't eject the cdrom:
only the first user can eject it.

Is there a way to avoid this? Being a home computer there are no privacy
issues: the cdrom drive is used just for CD ripping or burning, there's
no reason to prevent each other access to the unit.

Best regards.

-- 
Nimrod 

Re: Preventing ACL on cdrom drive...

[Thomas Schmitt]

Hi,

Nimrod wrote:
> the first user that logs in after boot locks the cdrom
> drive, and any other user that logs in can't eject the cdrom: only the first
> user can eject it.

Are you sure that it is the existence of the a user's ACL permission
which prevents the other's from ejecting and not their lack of own
permission ?

I understand from traces in the web, that on my Debian Jessie it is about
  SUBSYSTEM=="block", ENV{ID_CDROM}=="1", TAG+="uaccess"
in
  /lib/udev/rules.d/70-uaccess.rules
Rumor has it that "uaccess" causes the ACL.

The permission set of my /dev/sr0

  brw-rw+ 1 root cdrom 11, 0 Dec 23 12:26 /dev/sr0

is not narrowed by the desktop user's ACL but rather widened. So i would
assume that your whole family needs rw-permission. That could be achieved
here by putting them all into group "cdrom".


Have a nice day :)

Thomas

Re: Preventing ACL on cdrom drive...

[Pascal Hambourg]

Le 23/12/2016 à 18:54, Nimrod a écrit :


This is the issue: on a computer at home (shared among relatives, each
with his/her own account), the first user that logs in after boot locks
the cdrom drive, and any other user that logs in can't eject the cdrom:
only the first user can eject it.


I suspect that in order to eject the CD, you must first unmount its 
filesystem, but only the user who mounted it or root can unmount it if 
the CD drive has the "user" option in /etc/fstab. Try to replace "user" 
with "users" which allows any user to unmount it.

Re: Preventing ACL on cdrom drive...

[Nimrod]

Thanks for your kind answer, below is mine.

On Fri, 2016-12-23 at 20:30 +0100, Thomas Schmitt wrote:

> Hi,
> 
> Nimrod wrote:
> > the first user that logs in after boot locks the cdrom
> > drive, and any other user that logs in can't eject the cdrom: only the first
> > user can eject it.
> 
> Are you sure that it is the existence of the a user's ACL permission
> which prevents the other's from ejecting and not their lack of own
> permission ?

No, I'm lost in the deepest darkness.

> 
> I understand from traces in the web, that on my Debian Jessie it is about
>   SUBSYSTEM=="block", ENV{ID_CDROM}=="1", TAG+="uaccess"
> in
>   /lib/udev/rules.d/70-uaccess.rules
> Rumor has it that "uaccess" causes the ACL.

That's what I found too, but none of the adviced solution works.

> 
> The permission set of my /dev/sr0
> 
>   brw-rw+ 1 root cdrom 11, 0 Dec 23 12:26 /dev/sr0
> 

Here are mine:

brw-rw 1 root cdrom 11, 0 Dec 23 20:48 /dev/sr0

I see a "+" in your permission. What is that, and how could I get it
too?


> is not narrowed by the desktop user's ACL but rather widened. So i would
> assume that your whole family needs rw-permission. That could be achieved
> here by putting them all into group "cdrom".
> 

They all are already.

I add something I forgot to mention: sometimes I'm even prompted for
password to eject a CD I myself put into the drive!

> 
> Have a nice day :)

I'd rather hope to get in bed quite soon and sleep till 11 AM, but
thanks a lot anyway.

> 
> Thomas
> 

checking that all cpus are being used in my installation....

[Michael Fothergill]

​Dear Folks,

I am running Debian stretch on a pc with an AMD FX 8350 chip and a
sabertooth FX 990 motherboard.

I am interested to check a few things are working as they would be expected
to here.

I ran cat /proc/cpuinfo

and got

processor : 7
vendor_id : AuthenticAMD
cpu family : 21
model : 2
model name : AMD FX(tm)-8350 Eight-Core Processor
stepping : 0
microcode : 0x600084f
cpu MHz : 4013.300
cache size : 2048 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 23
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf
eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes
xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr
tbm topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall bmi1 arat npt
lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists
pausefilter pfthreshold
bugs : fxsave_leak sysret_ss_attrs null_seg
bogomips : 8026.82
TLB size : 1536 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro


​Does this seem reasonable?

Should the number of cpu cores be 8 rather than 4 (listed above)?

If you look at the discussion below:

https://ubuntuforums.org/showthread.php?t=2233301

Only one cpu was working out of all 8 for the original poster until they
turned the ACPI setting to ACPI=force apparently.

I suppose I could check the grub.cfg file in /boot or wherever it lives and
see what the ACPI setting is in my case.

In gentoo you set makeopts to -j9 and make =-j9 when you compile a fresh
kernel and then it should run quickly and as long as your power supply unit
is in good shape then things should go smoothly

In Debian I think there is something called makeflags but I am not sure
(comments appreciated here).

I am using kernel 4.8.2 I think.

I could download e.g. kernel 4.9.0 and then manually compile it using eg
make menuconfig and the existing .config file.

If I did that would it be make -j9 by default in debian or do I need to
specify that in the same way as you would in gentoo?

Also it should then compile pretty swiftly and smoothly (provided the power
supply is a good one) should it not?

Suggestions on performance testing the FX 8350 chip on this install are
welcome.

Regards

Michael Fothergill

Re: Preventing ACL on cdrom drive...

[Nimrod]

On Fri, 2016-12-23 at 20:54 +0100, Pascal Hambourg wrote:

> Le 23/12/2016 à 18:54, Nimrod a écrit :
> >
> > This is the issue: on a computer at home (shared among relatives, each
> > with his/her own account), the first user that logs in after boot locks
> > the cdrom drive, and any other user that logs in can't eject the cdrom:
> > only the first user can eject it.
> 
> I suspect that in order to eject the CD, you must first unmount its 
> filesystem, but only the user who mounted it or root can unmount it if 
> the CD drive has the "user" option in /etc/fstab. Try to replace "user" 
> with "users" which allows any user to unmount it.

There is no line about cdrom in /etc/fstab. Cdrom are usually mounted
under /media//cdrom or something like that. Since audio CD are not
mounted, any user can eject them. This could be a good point for your
suspicion (or is it "suspect"? Sorry, english is not my language).

Anyway, here is the output from mount about a CDROM:

/dev/sr0 on /media/andrea/CDROM type iso9660
(ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500,uhelper=udisks2)

Hope this is useful, thanks.


> 

Re: Preventing ACL on cdrom drive...

[Thomas Schmitt]

Hi,

Nimrod wrote:
> I see a "+" in your permission. What is that, and how could I get it too?

It indicates that there is a non-trivial ACL and that it is worth to run
program getfacl to see all permissions.

  $ getfacl /dev/sr0
  getfacl: Removing leading '/' from absolute path names
  # file: dev/sr0
  # owner: root
  # group: cdrom
  user::rw-
  user::rw-
  group::rw-
  mask::rw-
  other::---

I.e. my desktop user explicitely has rw permission independently of his
group memberships.


> > putting them all into group "cdrom".

> They all are already.

Consider Pascal Hambourg's theory that only the one can eject who mounted.

If the automounter (udisks ?) acts on your desktop user's behalf or on
its own user id, then permissions on the device file might be not enough
to operate it.

In this case you need to get your automounter under control.


> sometimes I'm even prompted for
> password to eject a CD I myself put into the drive!

What happens if the various users perform the command

  eject /dev/sr0

in a shell terminal ? Especially the superuser should have success.

Maybe you can enable all your family members to perform
  sudo eject /dev/sr0
and provide some icon for this command on the desktop. (I assume family
does not like shell commands.)


Have a nice day :)

Thomas

Re: Preventing ACL on cdrom drive...

[Nimrod]

On Fri, 2016-12-23 at 23:16 +0100, Thomas Schmitt wrote:

> Hi,
> 
> Nimrod wrote:
> > I see a "+" in your permission. What is that, and how could I get it 
> > too?
> 
> It indicates that there is a non-trivial ACL and that it is worth to run
> program getfacl to see all permissions.
> 
>   $ getfacl /dev/sr0
>   getfacl: Removing leading '/' from absolute path names
>   # file: dev/sr0
>   # owner: root
>   # group: cdrom
>   user::rw-
>   user::rw-
>   group::rw-
>   mask::rw-
>   other::---
> 
> I.e. my desktop user explicitely has rw permission independently of his
> group memberships.
> 
> 
> > > putting them all into group "cdrom".
> 
> > They all are already.
> 
> Consider Pascal Hambourg's theory that only the one can eject who mounted.
> 
> If the automounter (udisks ?) acts on your desktop user's behalf or on
> its own user id, then permissions on the device file might be not enough
> to operate it.
> 
> In this case you need to get your automounter under control.
> 
> 
> > sometimes I'm even prompted for
> > password to eject a CD I myself put into the drive!
> 
> What happens if the various users perform the command
> 
>   eject /dev/sr0
> 
> in a shell terminal ? Especially the superuser should have success.

Here is what happens when another user issues the "eject" command:

umount: /media/andrea/CDROM: Permission denied
eject: unmount of `/media/andrea/CDROM' failed

As you surely expected, root can eject the cdrom instead.

> 
> Maybe you can enable all your family members to perform
>   sudo eject /dev/sr0
> and provide some icon for this command on the desktop. (I assume family
> does not like shell commands.)
> 

It would work, but that would also be rather unaesthetic. Nevertheless I
will try this approach as a last choice.

> 
> Have a nice day :)
> 
> Thomas
> 

Re: checking that all cpus are being used in my installation....

[Ben Caradoc-Davies]

On 24/12/16 09:45, Michael Fothergill wrote:

Suggestions on performance testing the FX 8350 chip on this install are
welcome.


For an open source multithreaded CPU load with a handy benchmark mode, 
install povray, then run:


povray -benchmark

and compare the resulting time in seconds with:
https://openbenchmarking.org/showdown/pts/povray

(FX-8350 listed as 812 seconds.)

Your cpuinfo suggests that all 8 processors are detected. The "cpu 
cores" might refer to the four "modules" of this package, each with two 
integer and one floating point unit. POV-Ray is FPU intensive so expect 
quad-core performance.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Package upgrades why and how to avoid?

[Man_Without_Clue]

Hi all,

Couple days ago I was trying to general package update by simply "Mark
All Upgrades" and "Apply" from the Synaptic package manager as I usually do.

I noticed the audacious was up-gradable so I simply marked all upgrades
and tried to install. However I also noticed by doing this it will
remove other packages such as Skype, and others.

Why this happens and how to avoid this?


I guess just simply choosing upgrading all packages is not good idea.

Thanks

Re: Preventing ACL on cdrom drive...

[Michael Biebl]

Am 23.12.2016 um 18:54 schrieb Nimrod:
> Hi,
> 
> sorry for this trivial question, but I really tried to find an answer on
> the web without any result.
> 
> This is the issue: on a computer at home (shared among relatives, each
> with his/her own account), the first user that logs in after boot locks
> the cdrom drive, and any other user that logs in can't eject the cdrom:
> only the first user can eject it.
> 
> Is there a way to avoid this? Being a home computer there are no privacy
> issues: the cdrom drive is used just for CD ripping or burning, there's
> no reason to prevent each other access to the unit.

Does it help if you mount the cdrom as shared?
See https://udisks.freedesktop.org/docs/latest/udisks.8.html →
UDISKS_FILESYSTEM_SHARED

https://wiki.archlinux.org/index.php/udisks#Mount_to_.2Fmedia_.28udisks2.29



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature