On Fri, Jan 21, 2011 at 05:54:22PM +0100, Lennart Poettering wrote:
The FHS is kinda old these days, and it has been a while since it was
last updated. The LSB added some additional rules on top of it:
As long as we keep in mind that we don't follow the LSB at points where it
is ridiculous.
--
On 01/22/2011 06:22 AM, Matthew Miller wrote:
On Fri, Jan 21, 2011 at 05:54:22PM +0100, Lennart Poettering wrote:
The FHS is kinda old these days, and it has been a while since it was
last updated. The LSB added some additional rules on top of it:
As long as we keep in mind that we don't
On Thu, Jan 20, 2011 at 08:37:21AM +0100, Miloslav Trmač wrote:
Nathanael D. Noblet píše v Čt 20. 01. 2011 v 00:33 -0700:
On 01/19/2011 12:11 PM, Callum Lerwick wrote:
On Thu, Dec 23, 2010 at 11:26 AM, drago01drag...@gmail.com wrote:
Well /tmp should be mounted tmpfs anyway (I have been
On Fri, 21.01.11 15:01, Richard W.M. Jones (rjo...@redhat.com) wrote:
If /tmp is not supposed to be used for data that is inconvenient to
store in memory for whatever reason, and that should be automatically
removed when it is not used, what _is_ it supposed to be used for?
The FHS has
On Wed, Jan 19, 2011 at 01:11:08PM -0600, Callum Lerwick wrote:
On Thu, Dec 23, 2010 at 11:26 AM, drago01 drag...@gmail.com wrote:
Well /tmp should be mounted tmpfs anyway (I have been doing this for
years and it is working just fine).
tmp isn't a persistent storage so it makes a lot of
On 01/19/2011 12:11 PM, Callum Lerwick wrote:
On Thu, Dec 23, 2010 at 11:26 AM, drago01drag...@gmail.com wrote:
Well /tmp should be mounted tmpfs anyway (I have been doing this for
years and it is working just fine).
tmp isn't a persistent storage so it makes a lot of sense, and it is
*not*
Nathanael D. Noblet píše v Čt 20. 01. 2011 v 00:33 -0700:
On 01/19/2011 12:11 PM, Callum Lerwick wrote:
On Thu, Dec 23, 2010 at 11:26 AM, drago01drag...@gmail.com wrote:
Well /tmp should be mounted tmpfs anyway (I have been doing this for
years and it is working just fine).
tmp isn't a
On Tue, Jan 04, 2011 at 05:42:12PM -0800, Garrett Holmstrom wrote:
On Tue, Jan 4, 2011 at 4:31 PM, Bernie Innocenti ber...@codewiz.org wrote:
What sort of attack would this enable?
Wait... any unprivileged process can create sockets in the abstract
namespace? Uh-oh.
Any unprivileged
On Fri, 2011-01-07 at 11:46 +, Richard W.M. Jones wrote:
On Tue, Jan 04, 2011 at 05:42:12PM -0800, Garrett Holmstrom wrote:
On Tue, Jan 4, 2011 at 4:31 PM, Bernie Innocenti ber...@codewiz.org wrote:
What sort of attack would this enable?
Wait... any unprivileged process can create
On Mon, 03.01.11 22:12, Bernie Innocenti (ber...@codewiz.org) wrote:
On my desktop, abstract namespace sockets are twice more popular than
the regular ones:
ber...@giskard:~$ netstat -ax | grep @ | wc -l
151
ber...@giskard:~$ netstat -ax | grep -v @ | grep / | wc -l
73
Most uses
On Tue, 2011-01-04 at 14:11 +0100, Lennart Poettering wrote:
Misusing are ICE, X11, nspluginwrapper at least, since they do not use a
random socket name but a fixed one, hence opening the door to DoS attacks.
X's socket name isn't fixed. It's a function of whatever display name
you asked for
On Tue, 04.01.11 17:36, Adam Jackson (a...@redhat.com) wrote:
On Tue, 2011-01-04 at 14:11 +0100, Lennart Poettering wrote:
Misusing are ICE, X11, nspluginwrapper at least, since they do not use a
random socket name but a fixed one, hence opening the door to DoS attacks.
X's socket name
On Wed, 2011-01-05 at 00:59 +0100, Lennart Poettering wrote:
Well, OK, bad wording on my side. Replace fixed by guessable.
What sort of attack would this enable?
Wait... any unprivileged process can create sockets in the abstract
namespace? Uh-oh.
--
// Bernie Innocenti -
On Tue, Jan 4, 2011 at 4:31 PM, Bernie Innocenti ber...@codewiz.org wrote:
What sort of attack would this enable?
Wait... any unprivileged process can create sockets in the abstract
namespace? Uh-oh.
Any unprivileged process can prevent you from running X on a given
display by using up the
On Thu, 2010-12-23 at 22:59 +0100, Lennart Poettering wrote:
On Mon, 20.12.10 19:16, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu)
wrote:
this isn't exactly correct.
in /dev/shm on linux we have:
(a) unix-domain sockets for non-RT communication with the server
(b)
Once upon a time, Adam Jackson a...@redhat.com said:
Sadly this turns out not to be the case, at least if I'm reading
fs/pipe.c correctly. O_NOATIME will turn off atime updates, but mtime
and ctime are still modified on every pipe write, and there's no such
thing as O_NOCMTIME even though the
On Mon, 03.01.11 09:54, Chris Adams (cmad...@hiwaay.net) wrote:
Once upon a time, Adam Jackson a...@redhat.com said:
Sadly this turns out not to be the case, at least if I'm reading
fs/pipe.c correctly. O_NOATIME will turn off atime updates, but mtime
and ctime are still modified on
On Sat, 2010-12-25 at 19:37 +0100, Lennart Poettering wrote:
That basically means that besides systemd itself and maybe the D-Bus
system bus almost nobody can safely use fixed name abstract namespace
sockets. In particular user code that uses fixed name abstract namespace
sockets is
On Thu, Dec 23, 2010 at 09:11:46AM -0800, Fernando Lopez-Lezcano wrote:
On 12/22/2010 12:56 PM, Casey Dahlin wrote:
On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote:
This is from Paul Davis, the main architect of Jack (I forwarded him
your post):
this isn't
On 12/23/2010 01:52 PM, Lennart Poettering wrote:
On Mon, 20.12.10 13:07, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu)
wrote:
I raise this issue because The API for /dev/shm is shm_open()
statement above means to me that in the future there will be no file api
access to a ram mounted
On Fri, 24.12.10 16:17, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:
On 12/23/2010 01:52 PM, Lennart Poettering wrote:
On Mon, 20.12.10 13:07, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu)
wrote:
I raise this issue because The API for /dev/shm is shm_open()
statement
On Sat, 25.12.10 11:51, Casey Dahlin (cdah...@redhat.com) wrote:
Could you explain a bit perhaps? I'm not familiar with them... (or
maybe you have a url I could surf to?)
Basically, you put a \0 in front of the path when you bind the socket. So, for
example, bind to \0/jack/socket. Yes,
On 12/22/2010 12:56 PM, Casey Dahlin wrote:
On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote:
This is from Paul Davis, the main architect of Jack (I forwarded him
your post):
this isn't exactly correct.
in /dev/shm on linux we have:
(a) unix-domain sockets
On Thu, 2010-12-23 at 09:11 -0800, Fernando Lopez-Lezcano wrote:
On 12/22/2010 12:56 PM, Casey Dahlin wrote:
On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote:
(a) unix-domain sockets for non-RT communication with the server
Perhaps these could become abstract
On Tue, Dec 21, 2010 at 2:26 AM, Fernando Lopez-Lezcano
na...@ccrma.stanford.edu wrote:
On 12/20/2010 02:17 PM, Adam Jackson wrote:
On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
I would like to bring to the attention of the list another current usage
of the tmpfs mounted on
drago01 píše v Čt 23. 12. 2010 v 18:26 +0100:
Well /tmp should be mounted tmpfs anyway (I have been doing this for
years and it is working just fine).
tmp isn't a persistent storage so it makes a lot of sense, and it is
*not* a dumping ground for giant files (apps that try to do that are
just
On Tue, 14.12.10 21:11, Nicholas Miell (nmi...@gmail.com) wrote:
On 12/14/2010 07:28 PM, Lennart Poettering wrote:
In order to make things secure we minimize what is allowd on the various
API file systems we mount. That includes that we set noexec and similar
options for the file systems
On Thu, 16.12.10 22:02, Miloslav Trmač (m...@volny.cz) wrote:
Casey Dahlin píše v Čt 16. 12. 2010 v 15:50 -0500:
On Thu, Dec 16, 2010 at 08:16:53PM +0100, Miloslav Trmač wrote:
Especially minor changes that don't bring any measurable benefit
(perhaps making the system cleaner or making
On Wed, 15.12.10 08:44, John Reiser (jrei...@bitwagon.com) wrote:
I don't think there's a particularly good reason to use that filesystem for
other uses. Just mount another tmpfs elsewhere.
mount() requires CAP_SYS_ADMIN and therefore an application cannot rely
on performing mounts. A
On Mon, 20.12.10 13:07, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:
Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the
file api (apologies if my wording is not absolutely correct in unix
terms) on the tmpfs filesystem that is mounted on /dev/shm for a very
On Mon, 20.12.10 17:26, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:
In other words, these are setup costs, not maintenance costs. This may
cause glitches in a realtime scenario to the extent that clients are
created and destroyed, but in general I submit that the cost of
On Mon, 20.12.10 19:16, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:
this isn't exactly correct.
in /dev/shm on linux we have:
(a) unix-domain sockets for non-RT communication with the server
(b) FIFOs for RT wakeups (this could use semaphores now)
If this uses
On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote:
This is from Paul Davis, the main architect of Jack (I forwarded him
your post):
this isn't exactly correct.
in /dev/shm on linux we have:
(a) unix-domain sockets for non-RT communication with the server
On 12/14/2010 09:37 PM, Lennart Poettering wrote:
On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote:
The project is a database system that creates and dlopen()s
plugins on-the-fly, for better performance on [long-running] queries.
We like the speed of
On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
I would like to bring to the attention of the list another current usage
of the tmpfs mounted on /dev/shm in Fedora packages:
Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the
file api (apologies if my
On 12/20/2010 02:17 PM, Adam Jackson wrote:
On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
I would like to bring to the attention of the list another current usage
of the tmpfs mounted on /dev/shm in Fedora packages:
Jack (the Jack Audio Connection Kit, jackaudio.org) has
On 12/20/2010 05:26 PM, Fernando Lopez-Lezcano wrote:
On 12/20/2010 02:17 PM, Adam Jackson wrote:
On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
I would like to bring to the attention of the list another current usage
of the tmpfs mounted on /dev/shm in Fedora packages:
On Wed, Dec 15, 2010 at 07:21:25AM +0100, Lennart Poettering wrote:
Jeez. Tha's just FUD. Of course we have discussed this openly with
various folks. We haven't discussed this with you, Rich, personally, but
well, I'll make a note now tht I'll DoS you now with every single
choice we make, to
On Wed, Dec 15, 2010 at 07:17:21AM +0100, Lennart Poettering wrote:
systemd documentation is actually pretty good and mostly
comprehensive. Humble as I am I would even say that it is vastly
superior to the majority of all open source projects. If you want to
criticise us on something, pick
On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote:
On Wed, Dec 15, 2010 at 07:21:25AM +0100, Lennart Poettering wrote:
Jeez. Tha's just FUD. Of course we have discussed this openly with
various folks. We haven't discussed this with you, Rich, personally, but
well, I'll make
Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500:
On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote:
What you don't understand is that you are throwing away the experience
and knowledge of thousands of Unix system administrators. Almost of
all of them do not even read
On Thu, 2010-12-16 at 20:16 +0100, Miloslav Trmač wrote:
Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500:
On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote:
What you don't understand is that you are throwing away the experience
and knowledge of thousands of Unix system
On Thu, Dec 16, 2010 at 08:16:53PM +0100, Miloslav Trmač wrote:
Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500:
On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote:
What you don't understand is that you are throwing away the experience
and knowledge of thousands of Unix
Casey Dahlin píše v Čt 16. 12. 2010 v 15:50 -0500:
On Thu, Dec 16, 2010 at 08:16:53PM +0100, Miloslav Trmač wrote:
Especially minor changes that don't bring any measurable benefit
(perhaps making the system cleaner or making programmer's life more
convenient) but require time from each user
- John Reiser jrei...@bitwagon.com wrote:
On 12/14/2010 07:28 PM, Lennart Poettering wrote:
In order to make things secure we minimize what is allowd on the
various
API file systems we mount. That includes that we set noexec and
similar
options for the file systems involved. The
On Tue, Dec 14, 2010 at 10:19:38PM -0800, John Reiser wrote:
Also, the claim The API for /dev/shm is shm_open() is incorrect.
See the other message for the history. When something is in the file
system, then by default the file system APIs (including creat, open,
read, write, close, execve,
On 12/15/2010 06:40 AM, Matthew Miller wrote:
On Tue, Dec 14, 2010 at 10:19:38PM -0800, John Reiser wrote:
Also, the claim The API for /dev/shm is shm_open() is incorrect.
See the other message for the history. When something is in the file
system, then by default the file system APIs
On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski wrote:
the MS_NOEXEC flags is in private systemd fstab, see
systemd/src/mount-setup.c:
You're not kidding. Could the author of this code (I'm guessing...
Lennart?) please explain this extremely bright idea of
On Mon, Dec 13, 2010 at 09:47:49AM -0600, Garrett Holmstrom wrote:
If systemd is going to ignore fstab entries, could we please have the
fstab file on newly-installed systems replace the entries that would be
ignored with commentary that explains which filesystems will be ignored?
That
Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500:
On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski
wrote:
the MS_NOEXEC flags is in private systemd fstab, see
systemd/src/mount-setup.c:
You're not kidding. Could the author of this code (I'm guessing...
I will be away from 14 December 2010 to 7 January 2011. For Translate.org.za
and ANLoc queries, please contact the office: +2712 460 1095 or info AT
translate.org.za.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote:
Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500:
On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski
wrote:
the MS_NOEXEC flags is in private systemd fstab, see
systemd/src/mount-setup.c:
On 12/14/2010 02:24 PM, Tomasz Torcz wrote:
On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote:
Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500:
On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski
wrote:
the MS_NOEXEC flags is in private systemd fstab,
Once upon a time, Tomasz Torcz to...@pipebreaker.pl said:
We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
Those all directories are mounted _identically_ on every Linux distribution
down here.
Marcela Mašláňová píše v Út 14. 12. 2010 v 14:55 +0100:
On 12/14/2010 02:24 PM, Tomasz Torcz wrote:
On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote:
Changing the semantics of /etc/fstab without any consultation with
fedora-devel or even notification of Fedora that something
On Tue, Dec 14, 2010 at 02:24:53PM +0100, Tomasz Torcz wrote:
We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
Those all directories are mounted _identically_ on every Linux distribution
down
On Tue, 14 Dec 2010, Tomasz Torcz wrote:
We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
Those all directories are mounted _identically_ on every Linux distribution
down here. Why pollute fstab
On Tue, Dec 14, 2010 at 02:25:38PM +, Richard W.M. Jones wrote:
I think it's very reasonable to want to edit /etc/fstab to change the
default mount options of these filesystems. Suppose that /dev/shm
defaults to allowing suid and exec. At some point in the future a
security problem is
Marcela Mašláňová (mmasl...@redhat.com) said:
That's not a very constructive wording. Filing a bug showing your use-case
would be helpful.
I'd like to restate this point. It's rather disappointing that so many
people have decided to skip over this, and prefer to instead complain,
insinuate,
Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
The problem is not the technical solution. Problem is that changes of
such important thing like /etc/fstab are decided without Fedora developers.
Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get
mounted. When this
On 12/14/10 9:22 AM, Miloslav Trmač wrote:
Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
The problem is not the technical solution. Problem is that changes of
such important thing like /etc/fstab are decided without Fedora developers.
Eh, what? It's a change to how API filesystems
Once upon a time, Bill Nottingham nott...@redhat.com said:
having every system
installer have to write /proc, /sys, and so on is pretty wasteful.
I've seen this said at least a couple of times. In what way is it
wasteful? On most systems, /etc/fstab is going to be less than one
filesystem
Jesse Keating píše v Út 14. 12. 2010 v 09:47 -0800:
On 12/14/10 9:22 AM, Miloslav Trmač wrote:
Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
The problem is not the technical solution. Problem is that changes of
such important thing like /etc/fstab are decided without Fedora
Chris Adams (cmad...@hiwaay.net) said:
I've seen this said at least a couple of times. In what way is it
wasteful? On most systems, /etc/fstab is going to be less than one
filesystem block anyway, so there is absolutely zero waste going on.
If waste of a few dozen bytes is now an issue,
Miloslav Trmač (m...@volny.cz) said:
So the design was to
1) change the setting in the C reimplementation
The design was to pick a default... it's actually been that way since the
initial implementation and that *is* the default on some other distributions.
It probably should be relnoted,
On Tue, 2010-12-14 at 13:48 -0500, Bill Nottingham wrote:
And again, listing things like /sys in fstab can just give the
uninitiated the idea that it's something they can change... it's *not*
a configuration setting.
But I want to mount my /sys over nfs! What do you mean, it's not going
to
On Tue, Dec 14, 2010 at 02:25:38PM +, Richard W.M. Jones wrote:
On Tue, Dec 14, 2010 at 02:24:53PM +0100, Tomasz Torcz wrote:
We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
Those all
On Tue, 14 Dec 2010, Tomasz Torcz wrote:
Of course administrator can temporary override:
mount /dev/shm -o remount, nosuid
Or even have it stick after reboot, by droping in /etc/systemd/system/
following unit definition¹:
No.
You either follow what is in /etc/fstab, or you disallow it
On Tue, 14 Dec 2010, Bill Nottingham wrote:
It probably should be relnoted, sure.
A relnote is not a substitute for proper documentation, logging and man pages.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2010-12-14 at 17:54 -0500, Paul Wouters wrote:
On Tue, 14 Dec 2010, Tomasz Torcz wrote:
Of course administrator can temporary override:
mount /dev/shm -o remount, nosuid
Or even have it stick after reboot, by droping in /etc/systemd/system/
following unit definition¹:
No.
On Tue, 14.12.10 12:08, Bill Nottingham (nott...@redhat.com) wrote:
Thanks, Bill, for replying in so much detail.
Here are a few other points:
- systemd mounts API filesystems without them needing to be in
/etc/fstab. This is for a variety of reasons - having every system
installer have
On 12/14/2010 21:28, Lennart Poettering wrote:
On Tue, 14.12.10 12:08, Bill Nottingham (nott...@redhat.com) wrote:
Thanks, Bill, for replying in so much detail.
Here are a few other points:
- systemd mounts API filesystems without them needing to be in
/etc/fstab. This is for a variety
On 12/14/2010 07:28 PM, Lennart Poettering wrote:
In order to make things secure we minimize what is allowd on the various
API file systems we mount. That includes that we set noexec and similar
options for the file systems involved. The interface how to access
/dev/shm is called shm_open(),
On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote:
The project is a database system that creates and dlopen()s
plugins on-the-fly, for better performance on [long-running] queries.
We like the speed of creat+write+close+open+read+mmap on /dev/shm.
If /dev/shm and /tmp both
On 12/14/2010 07:28 PM, Lennart Poettering wrote:
In order to make things secure we minimize what is allowd on the various
API file systems we mount. That includes that we set noexec and similar
options for the file systems involved. The interface how to access
/dev/shm is called shm_open(),
On Tue, 14.12.10 13:53, Miloslav Trmač (m...@volny.cz) wrote:
Changing the semantics of /etc/fstab without any consultation with
fedora-devel or even notification of Fedora that something so
long-standing is changing is hardly constructive either.
I can happily live with systemd is a new,
On Tue, 14.12.10 08:08, Chris Adams (cmad...@hiwaay.net) wrote:
Once upon a time, Tomasz Torcz to...@pipebreaker.pl said:
We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
Those all
On Tue, 14.12.10 17:54, Paul Wouters (p...@xelerance.com) wrote:
On Tue, 14 Dec 2010, Tomasz Torcz wrote:
Of course administrator can temporary override:
mount /dev/shm -o remount, nosuid
Or even have it stick after reboot, by droping in /etc/systemd/system/
following unit
On 12/14/2010 09:37 PM, Lennart Poettering wrote:
On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote:
The project is a database system that creates and dlopen()s
plugins on-the-fly, for better performance on [long-running] queries.
We like the speed of
On Tue, 14.12.10 18:22, Miloslav Trmač (m...@volny.cz) wrote:
Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
The problem is not the technical solution. Problem is that changes of
such important thing like /etc/fstab are decided without Fedora
developers.
Eh, what? It's a
On Tue, 14.12.10 22:19, John Reiser (jrei...@bitwagon.com) wrote:
Also, the claim The API for /dev/shm is shm_open() is incorrect.
See the other message for the history. When something is in the file
system, then by default the file system APIs (including creat, open,
read, write, close,
On Sun, Dec 12, 2010 at 07:49:27PM -0800, John Reiser wrote:
How did /dev/shm get noexec in Fedora 15 rawhide?
$ grep /dev/shm /proc/mounts
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
$ grep -srl noexec /etc
/etc/alternatives/ld
/etc/fstab ## derived
On 12/13/2010 7:37, Karel Zak wrote:
On Sun, Dec 12, 2010 at 07:49:27PM -0800, John Reiser wrote:
How did /dev/shm get noexec in Fedora 15 rawhide?
$ grep /dev/shm /proc/mounts
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
$ grep -srl noexec /etc
Karel Zak k...@redhat.com wrote:
As a site administrator, how can I change the default to omit 'noexec'?
mount -o remount,exec ?
That's not really changing the default.
David
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hi,
On Monday, 13 December 2010 at 14:37, Karel Zak wrote:
On Sun, Dec 12, 2010 at 07:49:27PM -0800, John Reiser wrote:
How did /dev/shm get noexec in Fedora 15 rawhide?
$ grep /dev/shm /proc/mounts
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
$ grep -srl
85 matches
Mail list logo
